Shuttle FDO MFD

[DaveS]

Something weird is going on here with FDO MFD, the LWP only outputs negative figures as shown in the attached screenshot. Not sure what might be causing it. I have also included the SSV package for you check things out:

 

[indy91]

You chose launch day 180 in the config file, but June 27th is the 178th day of the year. If I use 178 there it gives me a good solution. Despite the input launch day, it will use current time as the initial guess. That's why it found the solution 2 days before your launch day, hence the negative numbers.

I was playing with the idea of changing this input to year/month/day in the executive menu, I think that would be better than having to look on Wikipedia each time what day of the year it is, and check if it's a leap year. Because that is what I am doing each time haha. Some displays would still show the GMT with the day of the year of course, because that's what they did in reality. Does that sound better?

 

[GLS]

I was playing with the idea of changing this input to year/month/day in the executive menu, I think that would be better than having to look on Wikipedia each time what day of the year it is, and check if it's a leap year. Because that is what I am doing each time haha.

If you're in the sim, go to panel O3 (above the PLT) and switch the timer there to GMT, and the day of the year will be displayed.

 

[indy91]

If you're in the sim, go to panel O3 (above the PLT) and switch the timer there to GMT, and the day of the year will be displayed.

Perfect, the astronauts telling the "flight controllers" what day it is so that they can calculate their launch accurately

I'll also discard all deorbit opportunities with a TIG before the input time to start the search, as you talked about in your previous post.

 

[GLS]

Perfect, the astronauts telling the "flight controllers" what day it is so that they can calculate their launch accurately

 

[thermocalc]

Hi Indy91,
just a curiosity:
from which book/manual you get the 3.9.7.3.7. generic PEG-4D target?
thanks.

 

[indy91]

Hi Indy91,
just a curiosity:
from which book/manual you get the 3.9.7.3.7. generic PEG-4D target?
thanks.

That is from the FDO Console Handbook, Volume 3, On-Orbit Trajectory Operations. I found it in the L2 subscriber section on the nasaspaceflight.com website. I hate that it is behind a paywall, but it still doesn't feel right to send this document out to everyone. It would be quite useful to any user of the FDO MFD. I'm very liberally quoting from it in the manual though .

On another topic, one thing I have noticed with NPC burns in a maneuver plan, they can easily screw up the calculation because it pushes following burns away from apogee/perigee. I had kind of solved that by putting an APO constraint in the STS-126 example plan, so forcing the maneuver after the NPC burn to happen at apogee. But this is not what the FDO Console Handbook usually does.

A version of the OMP was supposed to be in the Shuttle onboard computer, until that plan was abandoned in the mid-late 70s. But in the last document detailing how the onboard OMP would have looked like it does something special with NPC burns.

Let's say you are in an orbit with 90 minutes period and have these 3 maneuvers:

Maneuver	Threshold	Secondaries
NC-1	T = 000:03:00:00
NPC	M = 2.0	CN = 1.0
NC-2	M = 2.0

Let's assume NC-1 is at apogee. After NC-1 it goes 2 orbits further and starts searching for the NPC burn there (a common node with the target vehicle). The TIG of the NPC burn is then not at apogee anymore, because the common node can be anywhere in the next orbit. And then when the logic goes from NPC to NC-2 it continues for 2 orbits after the actual NPC TIG, meaning that the NC-2 TIG is also not at apogee.

But that seems to be wrong. There should be special NPC burn logic that doesn't find the NC-2 TIG at 2 orbits after the the NPC TIG, but at 2 orbits after the NPC threshold time (where it starts searching for NPC, 2 orbits after NC-1). That means that NC-2 will always be exactly 4 orbits after NC-1 in this case, also at apogee.

The FDO Console Handbook doesn't mention this anywhere, but if I look closely at one or two maneuver evaluation tables it the document then I am pretty sure that this is what happens with NPC maneuvers and the maneuver that follows it. And as I said, the memo about the onboard OMP is doing exactly this. If the constraint on NC-2 is any variant of M orbits after the NPC burn then it's counting the orbits from the NPC threshold time. And if the threshold is a DT (Delta Time) then it also counts from NPC threshold and not NPC itself. If the NC-2 threshold is a fixed time (T option) then it of course goes to that time without modification.

I have been a bit hesitant adding NPC burns to my plans because they tend to go bad, but I think with these changes it should work much better. This will be in the next version of the MFD.

 

[indy91]

A small update to the MFD:

-Easier initialization of launch date. Launch date and launch time are separately input now.
-Deorbit opportunties are discarded if their estimated time of ignition is earlier than the time to start searching.
-Added some single-vehicle maneuver types (node-shift and plane-change), fixed some others (circularization) and added several types of maneuver points (latitude, longitude, altitude, ascending node, descending node). Might be useful for some missions without rendezvous. Like, in the STS-1 flight plan the OMS-2 burn is a circ maneuver at 130 NM. Then OMS-3 would be a height maneuver up to 150 NM and lastly OMS-4 is a circ maneuver at 150NM altitude. Fairly simple, but should be possible to be calculated with the MFD. Just choose your own Shuttle as the target vessel if there is no rendezvous.

Enjoy!

Orbiter 2016: https://github.com/indy91/Shuttle-F...3.1-alpha-O2016/ShuttleFDOMFD_O2016_0.3.1.zip
Orbiter 2010: https://github.com/indy91/Shuttle-F...3.1-alpha-O2010/ShuttleFDOMFD_O2010_0.3.1.zip

 

[Snax]

Thank you for an Orbiter 2010 version !!

 

[indy91]

Another update:

-Various improvements to the Launch Window Processor. I had first implemented the LWP for the Shuttle, then I ported it to my RTCC MFD for NASSP to calculate launch time and parameters for Skylab launches and made various improvements to it in the process. Now I ported these improvements back into the FDO MFD. With non-spherical gravity enabled the nodal bias angle (DELNO) is now calculated automatically instead of finding the right value by trial and error. And with that all pieces are in place to generate a IY vector for the Shuttle ascent guidance to target. SSU/SSV still don't support that, so there is not much more I can do on the FDO MFD side. When that finally gets implemented I can do more updates to the LWP.
-Improved convergence of NPC burn solution in OMP. Also mostly with non-spherical gravity enabled. Should lead to a lot less "iteration failed" errors caused by having a NPC burn in the OMP plan.
-Added a few more save files with maneuver constraint tables. One file for STS-1, just for fun and showing that the MFD is also useful outside of rendezvous maneuvers. And then I added 4 example rendezvous plans for various phase angles to the rendezvous target. Loading these won't overwrite any other data like launch time or Shuttle name, so they are entirely generic. Should help with getting started on a new mission.

Orbiter 2010: https://github.com/indy91/Shuttle-F...3.2-alpha-O2010/ShuttleFDOMFD_O2010_0.3.2.zip
Orbiter 2016: https://github.com/indy91/Shuttle-F...3.2-alpha-O2016/ShuttleFDOMFD_O2016_0.3.2.zip

 

[DaveS]

I'm getting the "Too many iterations" error message when doing the pre-OMS-2 set up with STS-114. Not sure what is causing it. Everything looks good, yet when I try to calculate the initial Maneuver Evaluation Table, I get the "Error: Too many iterations" message in the Maneuver Constraints Table. This is with version 1.6 of SSV.

Could the ISS be in the wrong orbit in the SSV v1.6 STS-114 launch scenario and that is causing the error message?

 

[DaveS]

So after obtaining the actual historical orbital elements for the ISS on the actual launch day (July 26 2005) and using those, FDO MFD works just fine and can calculate the initial MET. So replace the ISS entry the STS-114 launch scenario with this block instead to have a valid launch scenario:

ISS:ProjectAlpha_ISS
  STATUS Orbiting Earth
  RPOS -1089213.665 -128643.694 -6643397.965
  RVEL 5557.5039 -5259.2452 -815.0759
  AROT 110.000 -10.000 80.000
  PRPLEVEL 0:1.000000
  IDS 0:1 100 1:2 100 2:3 100 3:4 100 4:5 100
  NAVFREQ 0 0
  XPDR 466
END

 

[indy91]

Great that you got it working! I guess the ISS was way out of plane of the Shuttle in that scenario?

I had actually neglected to post the latest update to the MFD from April, which goes together with the latest SSV release as well.

-Fix two NPC maneuver bugs. This should make things more stable with NPC burns in the OMP plan, hopefully leading to fewer "Error: Too many iterations".
-Some LWP display changes, but no major feature changes
-Change reference radius for heights from Orbiter Earth radius to real life Earth equatorial radius. This is what the actual Shuttle computer used as reference for apogee and perigee and such and it was changed in SSV recently as well. So it's a bit of an incompatibility with SSU now, but hopefully nothing too problematic. Just heights being shown are a few nautical miles different between MFD and SSU.

Orbiter 2016: https://github.com/indy91/Shuttle-F...3.4-alpha-O2016/ShuttleFDOMFD_O2016_0.3.4.zip

 

[DaveS]

Great that you got it working! I guess the ISS was way out of plane of the Shuttle in that scenario?

Yes, it was nowhere near KSC. The appropriate ascending node pass was probably a good 3-4 orbits away from a launch window opening. The TLE data brought it inline with the actual historical T0 of 1439:00 UTC on July 26 2005.

 

[GLS]

historical T0 of 1439:00 UTC on July 26 2005

But then Orbiter doesn't really run in UTC... but this is probably a discussion for another thread.

 

[indy91]

A major update to the MFD, the full Deorbit Maneuver Processor has been implemented. Most of the coding for this was done last year already, I was working on it at a very slow rate this year, but I think it's finally in a state that can be released.

It is based on the 1980 Flight Design System version of the targeting, which has a small number of simplifications. The document about it has full flowcharts though: https://web.archive.org/web/2010052...casi.ntrs.nasa.gov/19800070819_1980070819.pdf The likely superior version of the targeting would be found in the JSC requirements document, for which I know the memo number (76-FM-93), but it is not available on the Internet. It likely can be found at the National Archives and could be requested to be scanned though.

Here the section from the FDO Console Handbook about the targeting:

The DMP will generate a solution which conforms to the following guidelines:

1. The guidance targets calculated by the DMP processor are compatible with the onboard powered flight guidance.
2. The planned deorbit maneuver results in the achievement of a correlated V, gamma, and range set at EI. This target set is calculated by the Entry Target Generator (ETG) after being called by the DMP processor.
3. The deorbit maneuver is targeted to burn a specified amount of propellant, allowing achievement of landing weight or CG constraint.
4. The targeting is such that if the primary propulsion system fails to ignite, then a pre-designated backup propulsion system can perform the maneuver with no change in input guidance targets (including time of ignition (TIG)) and achieve nominal entry conditions.
5. In the TIG-free mode, the TIG is selected so that the same amount of Orbital Maneuvering System (OMS) propellant will be required for either prime or backup propulsion system with or without propellant wasting. A positive or zero propellant margin will result if the prime system fails during the burn.
6. The targeting ensures that minimal guidance and control transients will occur for a switchover from prime to backup thrusters anytime during the burn. Consequently, body attitude changes for fuel wasting must be small when reverting to the backup propulsion system.
7. If it is not desired to find the guidance targets that are biased for both prime and backup propulsion systems, a solution can be found for any single designated propulsion system by setting the backup equal to the primary.
8. Entry crossrange will be computed, and in the event that excess fuel is burned out-of-plane (OOP), it will be burned in a direction that will decrease crossrange.
9. The deorbit solution for any future orbit may be computed by inputting the appropriate TIG threshold time.
10. A TIG-free or TIG-fixed mode can be designated.
11. A minimum Time of Free Fall (TFF) (time from burnout to EI) constraint will be enforced by relaxing the requirement for equal OOP thrust angles until the TFF exceeds or equals the minimum TFF.

All of these apply to the implementation in the MFD, except for the Entry Target Generator, which is not implemented. It would require that a large section of the onboard entry guidance is implemented in the MFD, which I felt was a slightly excessive task for an initial release of the DMP. I might do it in the future though, if I can figure it out. Right now the reentry target line (flight path angle and range at as a function of velocity at EI) is based on a simple curve fit.

The output display contains just a minimum that is required for now. In reality there were a summary and a detailed display, but I felt it was a bit too much for the initial release.

I hope it is useful! Come at me with all the bugs you find haha.

Orbiter 2016: https://github.com/indy91/Shuttle-F...4.0-alpha-O2016/ShuttleFDOMFD_O2016_0.4.0.zip

 

[Johan2011]

How i can do the deorbit burn?

 

[indy91]

How i can do the deorbit burn?

Could you be a bit more specific? Are you asking how to calculate the burn with the FDO MFD? That should be covered in the manual. Any more specific question, feel free to ask them here!

 

[Johan2011]

How i can add a manuever?

 

[indy91]

How i can add a manuever?

ADD button on the maneuver constraints table. Have you checked the manual? It also has a walkthrough, although that was still written with SSU. Most of it should still apply with SSV.