Shuttle FDO MFD

[indy91]

This thread is for discussing my Shuttle FDO MFD which I created to plan realistic Shuttle rendezvous profiles. It's not strictly limited to SSU, but you would need something to execute PEG-7 targets (TIG and LVLH DV vector), so it will mostly be useful for SSU.

I've relased the source code here: https://github.com/indy91/Shuttle-FDO-MFD

I'm working on drafting a release with a dll build etc.

So here a description of what it currently can do. The description will be fairly similar to what is described in section 3.10 of the FDO Console Handbook, which I got by having a L2 subscription on the NASA Spaceflight website. Not sure if it is publically available anywhere.

There are currently 5 defined MFD pages:

-OMP Executive Menu for general settings.
-Maneuver Constraints Table for defining all the maneuver and constraints for the rendezvous profile.
-Maneuver Evaluation Table which displays lots of parameters for each calculated maneuver.
-Maneuver Transfer Table for making finite burns out of impulsive burns as they were calculated before.
-Detailed Maneuver Table which displays a bunch more numbers for a specific maneuver, right now only some numbers for a Maneuver PAD.

Executive Menu:

Here a few general settings can be made. CHASER is always the vessel from which you are opening the MFD. This should be the Shuttle (can be changed later so that it can be done from anywhere) right now. TARGET is the target for the rendezvous. The MFD looks for the ISS by default, but it can be freely chosen. LIFTOFF TIME is the reference time for any mission elapsed times displayed in the MFD. I have flown the STS-126 rendezvous as an example, so right now it's set by default to that launch time. Needs to be set to something different for other missions of course. PROPAGATION is the propagation method used by the MFD. Default is spherical gravity, non-spherical gravity already works, but still has a bunch of limitations, so I don't recommend it yet.

Maneuver Constraints Table:

Definitely the most complex page. Here you can define all the constraints for the rendezvous profile. Each maneuver has a maneuver type, a threshold for the time of ignition and secondary constraints. Secondary constraints can modify the TIG, in that case the threshold is just that, a threshold. Secondary constraints have various definitions.

Right now the MFD loads the STS-126 profile by default, but it should be possible to create any kind of profile. The profile usually depends on the phase angle of the Shuttle to the target at OMS-2, STS-126 was at roughly 270°. In that case the profile is like this:

OMS-2 targeted as a height maneuver (HA) at apogee (APO = 1.0) to a height in 180° travel (aka perigee) of 85NM (HD =85).

NC-1 is targeted for two orbits later (M = 2.0) as a phasing maneuver (type NC) with an initial guess of the DV of 100 ft/s (DV = 100)

NC-2 only exists to have a maneuver on Flight Day 2 that is not in any random direction, but planned to have a nominal 8 ft/s. So it's targeted as an External DV maneuver (EXDV), with the DV component 8, 0 and 0 ft/s (DVLV).

NPC is a plane change maneuver. Threshold time of 1 second to start searching just after NC-2, but the secondary constraint looks for a common node (CN) with the ISS, which will define the TIG.

NC-3 is the first maneuver on FD3. It's a height maneuver (NH), which sometimes seems to be called NH, but inconsistently sometimes NC as well. In the profile I found in the FDO handbook it was NC-3, so I am using that here. The TIG is 15.5 orbits after the previous maneuver (M = 15.5), although in this case it will ignore the TIG of the NPC maneuver and place the burn 15.5 revolutions after the burn before, NC-2.

NC-4 is another phasing maneuver (NC). The constraint placed on this burn are used for the previous NC type burn, so NC-1 will iterate on its DV to place the NC-4 maneuver at 40NM behind the target (DR = -40).

TI occurs one orbit after NC-4. The DR constraint placed on it will be achieved by the NC-4 burn, the desired height difference of 0.2NM (DH = 0.2) will be achieved by the NH/NC-3 burn, while the wedge angle (WEDG = 0.0), which is the difference in orbital planes between the two vessels is zeroed by the NPC maneuver on the previous day.

TI is a Stable Orbit Initiate (SOI) type of burn, so it's Lambert targeted and will try to achieve the specified offset at MC-4. In this plan MC-4 is just a stationkeeping maneuver (SOR), not the real onboard targeted MC-4 burn.

The real OMP supported a bunch more types of maneuvers, that will come later.


Maneuver Evaluation Table:

Not much to explain here, it just displays lots of relevant numbers for each burn. Maneuver name/type, comment/name, DV magnitude. Impulsive ignition time in GMT, mission elapsed time and delta time to the next burn. DV vector components in LVLH coordinates (ft/s). Apogee (HA), perigee (HP) heights and delta height to the target (DH). Range to target in NM, phase angle in degrees, time to noon or orbital midnight. Crossrange (Y), crossrange velocity (YDOT) and time to sunrise or sunset.

The best process is to have the MFD open twice, once with the constraints and once with the evaluation table. Change constraints until you are satisfied with the plan. Then next step is to transfer the burn data to the next display.

Maneuver Transfer Table:

Here you calculate the burns as finite ones, the previous displays assumped impulsive velocity change. There are 10 preset burn profiles that can be used. Manually changing them isn't supported yet. But basically it works like this:

Large burns use both OMS engines (OBP option). Option 1 and 2 are with TV ROLL set to 0 or 180. This will used for e.g. OMS-2, NC-1, NC-3 and NC-4 in this profile.

Mid range burns will use one OMS engine, either left (OL) or right (OR). I used those options for the NC-2 and NPC burns.

MC4 would be slot 9 (PX2), for a RCS burn. Slots 9 and 10 are special because they use the IMP option for the IMPULSIVE FLAG setting. When set to OPT the TIG will be moved to an earlier time equal to half the predicted burn time. This is done to get the same trajectory as an impulsive burn. Starting with TI (or maybe even NCC) the timeline is fixed, so it's desirable to calculate those burns at their impulsive TIG. When all the desired options are set the maneuver is transferred for use in the DMT.

Detailed Maneuver Table:

Here data about a specific burn are displayed, which can be chose from the previously calculated ones. It's only partially implemented, but it has the relevant numbers for use as a PEG-7 target.


I have attached a STS-126 scenario at a few minutes before OMS-2. I cheated the ISS orbit to be fairly in-plane with the Shuttle, but other than that it's a normal STS-126 launch with the SSU provided launch scenario. If you have the MFD you should be able to just go the maneuver constraints page and press CLC and the maneuver evaluation page will be filled with all the burn data.

In a future post I will describe the technique to get some additional constraints right (TI lighting and nulling DVZ component). I'm looking forward to see other people try and succeed a full rendezvous with this MFD!

EDIT: Now that I think about it, I hope the name of the MFD is no problem. Don't want anybody to be confused and think this is related to the Orbiter Multiplayer Project. Maybe I'll rename it to Shuttle FDO MFD or so.

 

[GLS]

Sometime this week I'll get bored with typing aerodata and I'll run a mission from pad to the ISS with this. Thanks!

EDIT: Now that I think about it, I hope the name of the MFD is no problem. Don't want anybody to be confused and think this is related to the Orbiter Multiplayer Project. Maybe I'll rename it to Shuttle FDO MFD or so.

That would make sense, if other FDO screens are added... :hmm: (keep reading)
Also, the code could be added to the SSU repository... :shrug:

FDO Console Handbook, which I got by having a L2 subscription on the NASA Spaceflight website. Not sure if it is publically available anywhere.

I found volumes IV (deorbit/entry) and V (ascent) long ago somewhere on the internet for free.

 

[indy91]

Sometime this week I'll get bored with typing aerodata and I'll run a mission from pad to the ISS with this. Thanks!

Sounds great. Different missions will have different profiles. I took the TIGs from the mission report to get the STS-126 profile right. Like, 3 hours between OMS-2 and NC-1? That sounds like 2.0 orbits. That kind of process.

That would make sense, if other FDO screens are added... :hmm: (keep reading)

Ah great, now I have to rename everything. :rofl:

Also, the code could be added to the SSU repository... :shrug:

Sure, when it's a bit more developed, debugged and tested and so on.

I found volumes IV (deorbit/entry) and V (ascent) long ago somewhere on the internet for free.

This is from Volume III, On-Orbit Trajectory Operations. I found it on L2 and felt very much inspired to implement some things from it in Orbiter. Previously I always had some doubts about certain procedures and constraints for the rendezvous, but this handbook has it all.

EDIT: Ok, project has been renamed.

 

[Wolf]

You are the man Indy. Thank you so much for your inspiration :hail:
I ve been waiting for something like this for ten years and now that you made it my PC went dead! I am the living proof of Murphy’s law

 

[indy91]

You are the man Indy. Thank you so much for your inspiration :hail:
I ve been waiting for something like this for ten years and now that you made it my PC went dead! I am the living proof of Murphy’s law

I am sure it's a buggy mess still, so you will get a better version... whenever your PC is fixed. :lol:

@GLS: Is the LaunchMFD of the LCC equal to MET = 0? Or is there any kind of time delay there. The Launch MJD is used as the reference for the MET in the MFD as well, so it's quite important that it's very accurate. Has to be manually added in the FDO MFD anyway, it's not reading from the LCC or anything like that.

And on that topic, during my STS-126 testing I usually had the MFD open twice as an external MFD. When I tried to implement saving/loading I noticed that nothing gets saved. Either because of an External MFD limitation or because SSU is already taking up all the scenario space for MFDs. So I'll probably have to save something outside of scenarios. Maybe mission specific configs that already have the rendezvous plan and liftoff time stored in them? Something like that...

EDIT: First release version is up: https://github.com/indy91/Shuttle-FDO-MFD/releases/tag/v0.1-alpha

 

[Wolf]

I am sure it's a buggy mess still, so you will get a better version... whenever your PC is fixed. :lol:

@GLS: Is the LaunchMFD of the LCC equal to MET = 0? Or is there any kind of time delay there. The Launch MJD is used as the reference for the MET in the MFD as well, so it's quite important that it's very accurate. Has to be manually added in the FDO MFD anyway, it's not reading from the LCC or anything like that

Really looking forward to it.
BTW did you find out what caused such a high DV for the STS-126 NPC burn?

 

[indy91]

Really looking forward to it.
BTW did you find out what caused such a high DV for the STS-126 NPC burn?

No, I haven't researched it much yet. But it's probably going to be a general issue. Only a perfect insertion by SSU (when the launch was in-plane) and a perfect ISS state vector in addition to using non-spherical gravity will give any reasonable DVs. I hope that it's not going to be 700-900 ft/s for other missions. I'll launch another mission, maybe some of the other scenarios have a better ISS state vector or so.

 

[Wolf]

No, I haven't researched it much yet. But it's probably going to be a general issue. Only a perfect insertion by SSU (when the launch was in-plane) and a perfect ISS state vector in addition to using non-spherical gravity will give any reasonable DVs. I hope that it's not going to be 700-900 ft/s for other missions. I'll launch another mission, maybe some of the other scenarios have a better ISS state vector or so.

Maybe the best option is to grt the correct state vectors from Celestrack and use them in your scenario. At least that should null any issues on that side

 

[GLS]

@GLS: Is the LaunchMFD of the LCC equal to MET = 0? Or is there any kind of time delay there. The Launch MJD is used as the reference for the MET in the MFD as well, so it's quite important that it's very accurate. Has to be manually added in the FDO MFD anyway, it's not reading from the LCC or anything like that.

I think so... The launch time is set in the LCC MFD, which is then sent to the RSLS, than then sets things in motion and starts the MET clock.

And on that topic, during my STS-126 testing I usually had the MFD open twice as an external MFD. When I tried to implement saving/loading I noticed that nothing gets saved. Either because of an External MFD limitation or because SSU is already taking up all the scenario space for MFDs. So I'll probably have to save something outside of scenarios. Maybe mission specific configs that already have the rendezvous plan and liftoff time stored in them? Something like that...

We have 11 MDUs/MFDs and they need to save stuff. I think MartinS upped the MFD limit to 12 back in 2015/16, because of us (thanks!). Not sure how the ExternalMFDs save things...
On the rendezvous plans, that was all planned ahead of the mission (to be sure it all worked), but was re-calculated in real-time to account for the actual data. The basic is launch time, which is a tricky thing as the countdown was not "automatically" targeted to the in-plane time, but was manually set to it at T-9 minutes (and I think there was another adjustment at T-11 hours). For now we only support countdowns from T-9 minutes down, so the launch time set in the mission file is the one used and no work from the user is needed.
On the orbital ballet, I think the profile is "standard" and only varies to accomodate (1) the phase angle at OMS-2, and (2) rendezvous MET (with lighting and groundtrack constraints). We could set 45h for this last one, and the phase angle is only known* after OMS-2, so for now we could only start worring about rendezvous after we get into orbit. (some phase angles don't allow a 2 day rendezvous, so a 3 day is needed...)

*) unless a flight plan is wanted pre-launch, in which case more math would be needed.

 

[indy91]

Maybe the best option is to grt the correct state vectors from Celestrack and use them in your scenario. At least that should null any issues on that side

I plugged in an ISS SV from a STS-126 Shuttle Fleet scenario, that works much better, 25 ft/s for NPC without the need to use the Scenario Editor on the ISS. So the main issue is probably Longitude of the Ascending Node of this ISS SV in the SSU STS-126 scenario. Inclination is also off by 0.06° (I could fix that in the mission specific config), but that is not much compared to the LAN error. So it's probably not going to that bad in other scenarios, luckily.

We have 11 MDUs/MFDs and they need to save stuff. I think MartinS upped the MFD limit to 12 back in 2015/16, because of us (thanks!). Not sure how the ExternalMFDs save things...
On the rendezvous plans, that was all planned ahead of the mission (to be sure it all worked), but was re-calculated in real-time to account for the actual data. The basic is launch time, which is a tricky thing as the countdown was not "automatically" targeted to the in-plane time, but was manually set to it at T-9 minutes (and I think there was another adjustment at T-11 hours). For now we only support countdowns from T-9 minutes down, so the launch time set in the mission file is the one used and no work from the user is needed.
On the orbital ballet, I think the profile is "standard" and only varies to accomodate (1) the phase angle at OMS-2, and (2) rendezvous MET (with lighting and groundtrack constraints). We could set 45h for this last one, and the phase angle is only known* after OMS-2, so for now we could only start worring about rendezvous after we get into orbit. (some phase angles don't allow a 2 day rendezvous, so a 3 day is needed...)

*) unless a flight plan is wanted pre-launch, in which case more math would be needed.

I based the revolutions between maneuvers etc. on the STS-126 mission report. Even in this flight where I had tweaked the ISS state vector and flew without nonspherical gravity my time of the TI maneuver was only off by 2 minutes from the flown mission, and the lighting was within seconds off the desired (TI maneuver happening 36 minutes before sunset). So that all worked really well. I just had to follow the instructions in the FDO handbook on how to manually move around some TIGs to make that work. I'll write about the process I used in another post.

For other missions we just have to look at when the rendezvous maneuvers were all done and derive from that what constraints have to be applied to all the maneuvers. Shouldn't be too hard to figure out.

EDIT: The end game is probably a launch window processor that calculates the right orbital plane vector (Iy) from the rendezvous profile, taking into account differential nodal regression, but that will of course require a bunch of SSU updates as well.

 

[Gingin]

Really nice nice work.
Can’t wait to test that back from holidays.
For NPC 700 fps was indeed huge, almost 0.7 degrees of Rinc
Happy to see it working with a better Sv.


That is really cool stuff, and Fido handbook Is really interesting.

Will it be workable for non spherical gravity and nodal precession?

 

[indy91]

Really nice nice work.
Can’t wait to test that back from holidays.
For NPC 700 fps was indeed huge, almost 0.7 degrees of Rinc
Happy to see it working with a better Sv.


That is really cool stuff, and Fido handbook Is really interesting.

Will it be workable for non spherical gravity and nodal precession?

It's mostly compatible with nonspherical gravity already, just some functions aren't added for it (like finding the time of the next apogee). Those are still calculated without the nonspherical gravity taken into account. Otherwise it seems to work quite well, even the plane change maneuver, just not really as well as it could br.

 

[GLS]

I plugged in an ISS SV from a STS-126 Shuttle Fleet scenario, that works much better, 25 ft/s for NPC without the need to use the Scenario Editor on the ISS. So the main issue is probably Longitude of the Ascending Node of this ISS SV in the SSU STS-126 scenario. Inclination is also off by 0.06° (I could fix that in the mission specific config), but that is not much compared to the LAN error. So it's probably not going to that bad in other scenarios, luckily.

Like I wrote in the development thread, I think the time in Orbiter is different from our "clock time", so both the launch time as well as the ISS SV conversion to Orbiter might need a time adjustment. This would affect the LAN positions for both vehicles. If we figure all of that out, there is also the issue of the shape of the Earth, which puts the pad in the wrong place, so in-plane times are different.

I based the revolutions between maneuvers etc. on the STS-126 mission report. Even in this flight where I had tweaked the ISS state vector and flew without nonspherical gravity my time of the TI maneuver was only off by 2 minutes from the flown mission, and the lighting was within seconds off the desired (TI maneuver happening 36 minutes before sunset). So that all worked really well. I just had to follow the instructions in the FDO handbook on how to manually move around some TIGs to make that work. I'll write about the process I used in another post.

For other missions we just have to look at when the rendezvous maneuvers were all done and derive from that what constraints have to be applied to all the maneuvers. Shouldn't be too hard to figure out.

Yes, and there are plenty of rendezvous for us to check any we create logic against.

EDIT: The end game is probably a launch window processor that calculates the right orbital plane vector (Iy) from the rendezvous profile, taking into account differential nodal regression, but that will of course require a bunch of SSU updates as well.

Yes, that would be something that would fit well in the SSU Workbench... you wouldn't happen to know C#? :hmm:
On the ascent guidance side of things, yes I'd really like to upgrade the launch, and get the plane targetting working, otherwise rendezvous is made very hard by the LAN errors. But that will only happen after the entry is finished and SSU 5.0 is out.

BTW: the MECO inclination target should +/- match the actual ISS inclination, instead of being the generic 51.6º it is on most mission files.

 

[Gingin]

That would be interesting to test it with sts 114 as we have the real data values in the fligh plan pdf .
It could be cool to cross checked tour tools with real data

I really can’t wait to test that

For the lan and launch window question, it takes indeed a bit of trick now
But still work by adjusting the launch time and launch MJD around 300 seconds before the descending node
Rinc below 0.1 degrees and NPC don’t exceed 50 to 100 fps max

I am also curious to know if for Ti you used only the ground targeted one from your software or if you cross checked it with spec 34 ?

So nice to have the ss/sr option .

 

[indy91]

Like I wrote in the development thread, I think the time in Orbiter is different from our "clock time", so both the launch time as well as the ISS SV conversion to Orbiter might need a time adjustment. This would affect the LAN positions for both vehicles. If we figure all of that out, there is also the issue of the shape of the Earth, which puts the pad in the wrong place, so in-plane times are different.

Haha, when I was looking at Apollo TLI targeting data I was having some thoughts like this about leap seconds and something being incompatible with the Orbiter J2000 system. Works quite well in general, so I am not too worried anymore.

Yes, and there are plenty of rendezvous for us to check any we create logic against.

Oh yeah, there are a lot of Shuttle missions with rendezvous..

Yes, that would be something that would fit well in the SSU Workbench... you wouldn't happen to know C#? :hmm:
On the ascent guidance side of things, yes I'd really like to upgrade the launch, and get the plane targetting working, otherwise rendezvous is made very hard by the LAN errors. But that will only happen after the entry is finished and SSU 5.0 is out.

I don't know C#, no. And I think it's not critical for most missions to have that capability, we just might have to adjust the liftoff time a bit to make things fit. So rather something for future SSU versions.

BTW: the MECO inclination target should +/- match the actual ISS inclination, instead of being the generic 51.6º it is on most mission files.

Yeah, for my STS-126 test it was 51.6° (Shuttle insertion) vs 51.66° (ISS orbit), so that will be a bunch more ft/s of error.

That would be interesting to test it with sts 114 as we have the real data values in the fligh plan pdf .
It could be cool to cross checked tour tools with real data

I can work out a modified rendezvous plan for STS-114. Just looking at some of those numbers, OMS-2 was again a height adjustment maneuver for maximum phasing putting the perigee at the minimum 85NM. In other cases OMS-2 could already be the first phasing maneuver. And then it already deviates from STS-126, because of some APU test that requires the computer to be in OPS 8 the NC-1 maneuver was moved one orbit late, so 3 orbits after OMS-2. And there is an additional NC maneuver, but it looks like it was cancelled, so probably just an additional phasing adjustment maneuver. Other than that it's probably a very similar profile.

I am also curious to know if for Ti you used only the ground targeted one from your software or if you cross checked it with spec 34 ?

So nice to have the ss/sr option .

I used the onboard targeted TI solution. It only differed by 0.1-0.2 ft/s anyway. SSU definitely did a good job executing the burns calculated with my MFD and then calculating the later rendezvous burns onboard. Small residuals and course corrections. All this with nonspherical gravity disabled of course.

---------- Post added 11th Feb 2019 at 15:53 ---------- Previous post was 10th Feb 2019 at 23:47 ----------

As promised, here some instructions on how to get the lighting right for the TI maneuver as well as the DV for that maneuver optimal by eliminating the DVZ component.

The usual desired lighting for TI is SS-36min, so the TI maneuver happening 36 minutes before sunset. I think this is required so that the Shuttle crew has a visual on the target (ISS) no later than the MC-3 maneuver. Also the rendezvous pitch maneuver would be rather pointless in darkness.

So here the initial plan.

The current lighting for TI is SS-53:49, which is off by about 18 minutes. The best way to get this fixed is by adjusting the TIG of the height maneuver on the day of rendezvous, in this case NC-3/NH. Right now the only constraint on it is that it happens 15.5 orbits (M = 15.5) after the previous maneuver. The NC-3 TIG on the evaluation table is 1:15:55:25, so we just add the 18 minutes to it and see if that makes a difference. The way to do this is pressing the threshold button (THR) and typing:"5 T 1:16:13:25". This sets the TIG (T) of the 5th maneuver in the constraints table (5) to the desired mission elapsed time. Then recalculate the solution (CLC). The TI lighting should now quite close to the desired, if you want to make it even more precise adjust the NC-3 TIG again. This procedure gave me the following tables:

The TI lighting is now spot on. But the TI DV vector has become +9.06 +0.0 +27.7. That's of course a very suboptimal burn and has to do with the line of apsides not being aligned between the Shuttle and the ISS. Now, the best way to fix that is to again iterate manually on a large and early burn. The best choice for this is NC-1. Just adjust the TIG like previously done with the NC-3 maneuver. First maybe by 1 minute to see if moving the TIG forward or backwards will improve the TI DVZ. After a bit of iterating my tables look like this:

TI DVZ is now down to 0.17 ft/s and the lighting has only shifted by 4 seconds. So the desired lighting and optimal DV has now been achieved!

 

[GLS]

Haha, when I was looking at Apollo TLI targeting data I was having some thoughts like this about leap seconds and something being incompatible with the Orbiter J2000 system. Works quite well in general, so I am not too worried anymore.

From that reliable source called wikipedia:

J2000.0

The current standard epoch is called "J2000.0" This is defined by international agreement to be equivalent to:

The Gregorian date January 1, 2000 at approximately 12:00 GMT (Greenwich Mean Time).
The Julian date 2451545.0 TT (Terrestrial Time).[8]
January 1, 2000, 11:59:27.816 TAI (International Atomic Time).[9]
January 1, 2000, 11:58:55.816 UTC (Coordinated Universal Time).[a]

If that is correct, and if I understand it well, Orbiter is 64.184s "ahead" of our wrist watch... that's a lot of time. :uhh:

 

[Donamy]

Any way to make Orbiter do a fall minute ?

 

[indy91]

It's possible that the positions of the planets and moons in Orbiter are off by 64 seconds from what we expect, I guess. But the rotational state of the Earth can't really be that much off. The Earth config probably has an initial rotational state that is compatible with GMT, although I am not really sure about this.

 

[GLS]

It's possible that the positions of the planets and moons in Orbiter are off by 64 seconds from what we expect, I guess. But the rotational state of the Earth can't really be that much off. The Earth config probably has an initial rotational state that is compatible with GMT, although I am not really sure about this.

Even if the Earth is "where it is supposed to be", the ISS SV conversion could be wrong.

 

[Urwumpe]

It's possible that the positions of the planets and moons in Orbiter are off by 64 seconds from what we expect, I guess. But the rotational state of the Earth can't really be that much off. The Earth config probably has an initial rotational state that is compatible with GMT, although I am not really sure about this.

I suspect the position of the planets is right, but the rotation axis and velocity not over a longer period of time.



One way to check this would be comparing Earths axis and rotation with the global coordinate system at different times.



And I would be even more surprised if the star positions are correct over 50 years. :lol: