OHM TESS

[BrianJ]

It probably does not add to the entry speed. But the nose of the rocket does point below the horizon, so the apoapsis of the 1st stage is lowered during the boostback I would say.

What it certainly does do is to reduce time-until-impact, so you need a higher horizontal velocity component to reach your target.

As ever, we don't know what the primary constraint is on the 1st stage boostback trajectory and reentry conditions. My add-on uses a "minimum-energy" ballistic trajectory, but SpaceX might use a "minimum-required-impulse", or perhaps flight-angle at reentry is important, etc. Go figure!

Cheers,
BrianJ

 

[jgrillo2002]

OK this trajectory is not easy. How does one accomplish this? TransX? or Lagrange MFD

 

[BrianJ]

Hi,
not a straight forward lunar transfer, for sure.
You can use IMFD Surface Launch or TransX to plan the launch for lunar intercept in about 26days, or just launch at historical time/azimuth.

IMFD Delta Velocity or TransX for the burn to push ApA to 275000km, keep the ApA on the line of nodes of Earth/Moon orbit intersection.

Then you have 3.5 phasing orbits before lunar flyby.
You need to make correction burns at each(or some) perigee, for lunar intercept.
My method:
Use IMFD Course - Target Intercept
Target moon at the intercept date. Set burn ignition time to the perigee before lunar intercept (3.5-4days before intercept) (this will move as you make correction burns and your orbit changes, so adjust each time).
Make prograde correction burn at each perigee to reduce dV required by IMFD Course-Target Intercept by 50% (watch the dV required as you make the burn).

At the final perigee before lunar flyby, dV required by IMFD Course-target Intercept should be minimal and you can use IMFD to make the final intercept burn.

Once I have a lunar intercept set up, I switch over to TransX to plan the flyby for 37deg inc. and nominal PeA (can't remember the figure now ~117000km) orbit.

At first Earth perigee after flyby you can adjust the ApA to get a nice stable orbit for 1-2 years (check using IMFD Map or LagrangeMFD plot).

Hope this helps
BrianJ

 

[jgrillo2002]

That is still a little complicated. the problem is burning at the right angle at the right time. Not to mention the correct altitude to keep up with the moon. What altitudes did you use for the 2nd and third burns?

 

[BrianJ]

That is still a little complicated. the problem is burning at the right angle at the right time. Not to mention the correct altitude to keep up with the moon. What altitudes did you use for the 2nd and third burns?

Hi,
do you mean 2nd and 3rd "phasing orbit" burns? IIRC, during the 1st phasing orbit, perigee is pulled up(by Moon gravity) to ~1000km alt, it doesn't vary much from there, so 2nd and 3rd burns are at ~1000km.

As per previous post, my "trick" is to set up IMFD Course - Target Intercept for a TLI burn close to final perigee (~4days before Moon intercept).
At each phasing orbit perigee, make a prograde burn to reduce dV required for TLI burn to minimum.


Cheers,
Brian

 

[ZacharyS41]

Several sources say that the total mass of TESS is 362 kilograms rather than 365 kilograms, and I'm working on changing the dry mass to match that number.

However, I'm not an expert in Visual Studio. What's the easy way to figure this out?

 

[BrianJ]

Several sources say that the total mass of TESS is 362 kilograms rather than 365 kilograms, and I'm working on changing the dry mass to match that number.

However, I'm not an expert in Visual Studio. What's the easy way to figure this out?

If you're recompiling from the source code, just change the EMP_MASS value, it's up at the top of tess.cpp. You'll need to link OrbiterSoundSDK40.lib also.



Or an easy way to do it, I think, is to add a Mass parameter to the .cfg.
Config/ Vessels/ Tess/ tess.cfg

Mass = 317

I think that will override the .dll mass.

 

[ZacharyS41]

Thanks, BrianJ. Adding the mass parameter saved me a bunch of time.

 

[Ajaja]

An interesting video tutorial for GMAT (General Mission Analysis Tool) where the TESS trajectory calculation is described.
The trajectory is slightly different (it was 2014) but there is the same idea.

And GMAT 2018a already has an optimizator (Yukon) which can be used instead of proprietary VF13ad or Matlab to calculate such trajectories, and it works fine even with these TESS tutorials scripts.
An amaizing tool for mission planning

 

[Nicholas Kang]

Or you can use the exact same software that JPL uses.

MONTE: https://montepy.jpl.nasa.gov/

I used GMAT once but I remember certain source codes and optimization algorithms are not made public and require commercial license to use them.

On the other hand, though MONTE is not open-source, all APIs are fully available, including the optimization algorithms. The source code is written in C++ and wrapped with Python 2.

MONTE only runs on Red Hat-based Linux OSes (RHEL and CentOS) and is not released for individuals but for academic research and commercial usage only, i.e. you have to apply it through your college/university/company.

EDIT: Just recall that TESS is a Goddard mission, not JPL's. So Goddard's in-house GMAT should give a result closer to prediction. But MONTE is worth trying though.

 

[Ajaja]

I used GMAT once but I remember certain source codes and optimization algorithms are not made public and require commercial license to use them.

Now it has an opensource optimization plugin (Yukon), and you don't need proprietary tools (VF13ad/Matlab) anymore.

MONTE only runs on Red Hat-based Linux OSes (RHEL and CentOS) and is not released for individuals but for academic research and commercial usage only, i.e. you have to apply it through your college/university/company.

Then I'm afraid it will be useless with my Windows 7

EDIT: Just recall that TESS is a Goddard mission, not JPL's. So Goddard's in-house GMAT should give a result closer to prediction.

Yes, they really used GMAT for TESS mission, there is even "Generated by the General Mission Analysis Tool (GMAT)" text inside old ephemeris files ( https://spsweb.fltops.jpl.nasa.gov/portaldataops/ephemerides/TESS/ )

 

[Nicholas Kang]

Now it has an opensource optimization plugin (Yukon), and you don't need proprietary tools (VF13ad/Matlab) anymore.

Thanks for the info, Ajaja. I think you are referring to this: gmat.sourceforge.net/doc/R2018a/html/Yukon.html

(I didn't know R2018a has been released. :lol: Probably missed it. Should check the news more often.)

Then I'm afraid it will be useless with my Windows 7

MONTE is cool, I think. You should try learning Linux. It is fun. I dual-booted my PC with Windows 10 alongside CentOS.

IIRC, JPL uses Linux (RHEL) in planning mission trajectories. Not sure about Goddard. Since GMAT is available as a Windows application, I assume they run optimziations on Windows platforms.

Yes, they really used GMAT for TESS mission, there is even "Generated by the General Mission Analysis Tool (GMAT)" text inside old ephemeris files ( https://spsweb.fltops.jpl.nasa.gov/portaldataops/ephemerides/TESS/ )

Ya, I know that. Saw TESS's profile in several NASA documents. Will be more careful next time before posting.

 

[BrianJ]

JPL calls their mission planning software "Monte Python" ??!? :-D
Must have another look at GMAT, tried it years ago but got distracted by other things.
Thanks,
Brian