Shuttle FDO MFD

[indy91]

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

Yeah, certainly can. In the case of the STS-126 launch scenario it could be other things as well. The ISS state vector was changed when the launch scenario was moved from T-11 hours to L-10 minutes, in this revision: https://sourceforge.net/p/shuttleultra/code/1546/ If, for example, the new ISS state vector was generated by coasting for that half of a day and nonspherical gravity was disabled during this procedure, then the error in the longitude of the ascending node would exactly fit with what we get after insertion. Maybe DaveS knows what he did there 5+ years ago. :lol: I haven't tried yet to load an accurate TLE for the ISS, but I have a feeling most of the LAN error would go away.

I have decided how I want to solve the saving/loading issue. The MFD will have saving and loading buttons in the settings menu. There you can save or load e.g. a "STS-126.txt" file in a MFD specific folder, probably in Config/MFD/ShuttleFDOMFD. There launch time etc. will be saved and in the future also the TIG-less rendezvous plan to load up for planning before OMS-2. And of course during a mission you will be able save rendezvous plans in any file you want. But I could also include the flown rendezvous plans for a bunch of missions with the MFD directly. The only downside of not using the normal MFD saving/loading will be that no parameters are saved in a scenario. So step 1 after loading a scenario where you want to use the MFD will always be to load the right mission file. Not too inconvenient I think.

---------- Post added at 19:31 ---------- Previous post was at 19:24 ----------

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

NASSP uses a slightly modified Earth config to compensate for, what I think is, mostly Earth rotation speed not being constant.

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

They are not. At least not the ones with large proper motion. The AGC has hardcoded star tables and you can see a small difference for some stars in Orbiter vs. where the AGC thinks they should be. This is solved by using star markers, which shows where you should be make your sextant marks instead of on the star in the Orbiter sky. But the difference is not significant enough to cause any bigger trouble, you could probably get away with now using the markers.

 

[GLS]

I have decided how I want to solve the saving/loading issue. The MFD will have saving and loading buttons in the settings menu. There you can save or load e.g. a "STS-126.txt" file in a MFD specific folder, probably in Config/MFD/ShuttleFDOMFD. There launch time etc. will be saved and in the future also the TIG-less rendezvous plan to load up for planning before OMS-2. And of course during a mission you will be able save rendezvous plans in any file you want. But I could also include the flown rendezvous plans for a bunch of missions with the MFD directly. The only downside of not using the normal MFD saving/loading will be that no parameters are saved in a scenario. So step 1 after loading a scenario where you want to use the MFD will always be to load the right mission file. Not too inconvenient I think.

How about creating an "empty" vessel called SSU_MCC, and have the MFD inside it? You could access the (planned) launch time by reading the mission file, and any settings would be saved by the vessel. :shrug:
In the future, the actual launch time could be obtained via telemetry (as well as other parameters).
The only issue I see is that this architecture would limit your MFD to SSU...

 

[Urwumpe]

How about creating an "empty" vessel called SSU_MCC, and have the MFD inside it? You could access the (planned) launch time by reading the mission file, and any settings would be saved by the vessel. :shrug:

Why not both? Have the MFD now and be very happy about it and LATER develop a version that can be better integrated into playing with SSU. Somebody has to code it.



If indy91 would like to make our life easier later, he could split the MFD into two DLLs, one for the MFD front-end and one with the mathematical backend.

 

[indy91]

How about creating an "empty" vessel called SSU_MCC, and have the MFD inside it? You could access the (planned) launch time by reading the mission file, and any settings would be saved by the vessel. :shrug:
In the future, the actual launch time could be obtained via telemetry (as well as other parameters).
The only issue I see is that this architecture would limit your MFD to SSU...

One general limitation of MFD saving is that you have to have it open when you close Orbiter, or else nothing will be saved in the scenario. So having that separate loading of parameters and rendezvous plans is something I want to have anyway.

I have no problem with running the MFD in a SSU_MCC vessel, might even be better than having to use the External MFD which gives me a bit of trouble sometimes (input box seems buggy). For now I'll not make the MFD completely SSU specific, although that might happen in the future when I want to access some numbers from it.

 

[Urwumpe]

I have no problem with running the MFD in a SSU_MCC vessel, might even be better than having to use the External MFD which gives me a bit of trouble sometimes (input box seems buggy). For now I'll not make the MFD completely SSU specific, although that might happen in the future when I want to access some numbers from it.

Well, another advantage would be that we plan anyway to include flight plans into the mission file system of SSU one soon day and this information could be used to simplify the operations of such a MFD a lot. But then, this information could also be provided to an general MFD with a suitable API.

 

[indy91]

Well, another advantage would be that we plan anyway to include flight plans into the mission file system of SSU one soon day and this information could be used to simplify the operations of such a MFD a lot. But then, this information could also be provided to an general MFD with a suitable API.

Yeah, a mission file would basically need the same parameters as listed on the Maneuver Constraints Table. If SSU ever gets that, then it should be easy to make the MFD load it.

Updated the repo with the latest state of development and created a new release zip file: https://github.com/indy91/Shuttle-FDO-MFD/releases/tag/v0.1.1-alpha Being able to save and load the launch time is the first, very small, step to make the MFD less of a hassle to use with any other mission than STS-126. I'll continue to work on that, probably by test flying STS-114.

EDIT: Ah, and in terms of new features, the Maneuver PAD is much more complete now. It calculates burn attitude, velocity-to-go etc. The calculated gimbal trim angles are calculated from the offset that actually seems to exists between OMS and Shuttle CG. I know SSU simulates a shifting CG in some way at least. The pitch trim angle I am getting is more like -0.1° instead of 0.4°-0.5° which seems to be the usual value. I can hardcode any angles if that works better with SSU procedures.

 

[Urwumpe]

The COG shift during orbital operations is less realistic as it could be, we mostly ignore it, despite having all the necessary data to implement it at least as good as mission control had it. :lol:

 

[DaveS]

The COG shift during orbital operations is less realistic as it could be, we mostly ignore it, despite having all the necessary data to implement it at least as good as mission control had it. :lol:

I believe it is due to us not simulating the c.g shifts of the ever depleting RCS/OMS propellant tanks. Instead we use Orbiter's own handling of that (IOW, there's no shift as Orbiter assumes propellant tanks to be point masses located at 0,0,0).

 

[indy91]

I've implemented it in such a way that I can supply the CG of the whole vehicle to a function and that calculates the trim angles. So if anything in SSU changes it can easily be adjusted in the MFD.

Oh, and fun fact. Testing the STS-114 launch scenario is a bit difficult right now, because it's doesn't even have a ISS in it! :rofl: The scenario "Historic missions\STS-114\Launch.scn" that is. The "Post-OMS2.scn" scenario has an ISS. Guess I'll try some other mission. At least it has already helped me fix some bugs.

 

[Wolf]

I've implemented it in such a way that I can supply the CG of the whole vehicle to a function and that calculates the trim angles. So if anything in SSU changes it can easily be adjusted in the MFD.

Oh, and fun fact. Testing the STS-114 launch scenario is a bit difficult right now, because it's doesn't even have a ISS in it! :rofl: The scenario "Historic missions\STS-114\Launch.scn" that is. The "Post-OMS2.scn" scenario has an ISS. Guess I'll try some other mission. At least it has already helped me fix some bugs.

I have a launch scenario with the ISS (State vectors according to Celestrack around launch date/time) but unfortunately I can’t post it due to my pc gone.
Other options could be checking out the STS-114 Shuttle Fleet or Thorton’s ISSR launch scenario and get the ISS data from there (assuming they have the correct state vectors)

 

[Urwumpe]

I believe it is due to us not simulating the c.g shifts of the ever depleting RCS/OMS propellant tanks. Instead we use Orbiter's own handling of that (IOW, there's no shift as Orbiter assumes propellant tanks to be point masses located at 0,0,0).

Yes - but we care for trim angles. :lol: It wouldn't actually be a big issue to implement it, AFAIR, we already have split the fuel resources fine enough to allow implementing it with a single abstraction layer between implementation of the fuel resources and the algorithm to calculate the CoG shift.

 

[indy91]

Simulating that makes my job more difficult as well, haha, right now I can simply assume the offset between OMS and CG as constant. I also looked at the SSU code first to derive this offset, but what the Orbiter API gave me (GetThrusterRef) was different, so I assumed some CG shifting was doing it. That probably is still the case, but by a fixed amount that I couldn't quite figure out from looking at the code alone. Anyway, the trim angles I am calculating (which could be wrong anyway) gives me results very close to what is expected (-0.1° vs. 0.4-0.5°), but not exactly spot on. So I can treat it either way. Present the trim angles on the PAD as I think they are right in the current configuration, or hardcode to 0.4°/-5.7°/5.7° etc.

 

[Urwumpe]

Well, if you would need such vessel specific information, maybe we can talk about providing something like a "microservice" in Orbiter for you to query such information in the SSU case - and ignore it for all others.

 

[indy91]

Well, if you would need such vessel specific information, maybe we can talk about providing something like a "microservice" in Orbiter for you to query such information in the SSU case - and ignore it for all others.

I think it's better to keep it as separate as possible. I'm sure FDOs had some nice software to calculate the Shuttle CoG, but they didn't have a way to know it exactly while in orbit. I'll take more of an external approach and try to not ask too much, if anything directly from the SSU code.

On a different topic, I don't have a clear picture of what in the SSU code assumes nonspherical gravity to be enabled or not. In the LambertBurnTargeting code for example there is a reference to the J2 coefficient. So in general, is there any restriction on running SSU with/without nonspherical gravity? Or does it not make much of a difference right now for e.g. state vector propagation.

 

[GLS]

As I understand it, the trim angles are just to set the OMS positions pre-burn (and maybe vehicle attitude?... can't remember now :S). As soon as they ignite, it starts looking for the c.g., regardless of what the initial angles were. Of course, if one inputs the trim angles such that they engines point thru the c.g., there will be no "search", thus the burn will be a bit more efficient, but IMO it isn't something super-important that needs to be (accurately) calculated.

 

[indy91]

As I understand it, the trim angles are just to set the OMS positions pre-burn (and maybe vehicle attitude?... can't remember now :S). As soon as they ignite, it starts looking for the c.g., regardless of what the initial angles were. Of course, if one inputs the trim angles such that they engines point thru the c.g., there will be no "search", thus the burn will be a bit more efficient, but IMO it isn't something super-important that needs to be (accurately) calculated.

Yeah, I was mostly asking if I should calculate it "right" which could confuse people if the pitch angle is a little bit off from what you expect from any standard Shuttle documentation. So just a procedure thing really. I read that the OMS gimbal software doesn't even start moving the gimbal, if the error isn't at least 0.4°. Apollo 9 actually did a fun test where they had the trim gimbal angle off by 0.5° on purpose to test the reaction of the DAP and CSM+LM stack. Probably gave a more dramatic effect than it would have on the Shuttle. Anyway, it seems to be a detail question with not much relevance.

 

[GLS]

I read that the OMS gimbal software doesn't even start moving the gimbal, if the error isn't at least 0.4°.

Yes, the gimbal has a 0.4º hysteresis.

 

[indy91]

Fixing bugs and testing the STS-114 Post OMS-2 scenario right now. The ISS state vector in that scenario is also not all that good. So I installed the Scenario Editor TLE addon and found a TLE for the ISS online that is from 8 days before the STS-114 launch (a bit dated, could probably be improved). And look at that, the NPC burn would only be 8 ft/s! That is with the nonspherical gravity calculations enabled, without that it would be 100+ ft/s. The inclination of ISS and Shuttle are perfectly aligned, just the LAN is off as expected, but will fix itself by FD3 due to orbital mechanics. So that is quite encouraging. The planes were aligned so well, that my TIG search function for the NPC burn broke down. But that seems to have been the case in the real Orbital Maneuver Processor as well, when the wedge angle between the Shuttle and ISS orbits was below 0.01°.

 

[Wolf]

Fixing bugs and testing the STS-114 Post OMS-2 scenario right now. The ISS state vector in that scenario is also not all that good. So I installed the Scenario Editor TLE addon and found a TLE for the ISS online that is from 8 days before the STS-114 launch (a bit dated, could probably be improved). And look at that, the NPC burn would only be 8 ft/s! That is with the nonspherical gravity calculations enabled, without that it would be 100+ ft/s. The inclination of ISS and Shuttle are perfectly aligned, just the LAN is off as expected, but will fix itself by FD3 due to orbital mechanics. So that is quite encouraging. The planes were aligned so well, that my TIG search function for the NPC burn broke down. But that seems to have been the case in the real Orbital Maneuver Processor as well, when the wedge angle between the Shuttle and ISS orbits was below 0.01°.

That sounds very very promising :thumbup:
Can you explain how non spherical gravity sources is able to reduce that much the DV of the NPC burn? Being totally ignorant on this matter I would expect the opposite (the more the variables enabled the more the “error”)

 

[indy91]

That sounds very very promising :thumbup:
Can you explain how non spherical gravity sources is able to reduce that much the DV of the NPC burn? Being totally ignorant on this matter I would expect the opposite (the more the variables enabled the more the “error”)

Sure. It's caused by nodal regression: https://en.wikipedia.org/wiki/Nodal_precession

This effect acts on the orbit of both the Shuttle and the ISS and pulls both orbits "westwards". But this effect is also depending on the altitude of a satellite and it's going to be stronger for a vessel in a lower orbit. Now, the Shuttle spent about 2 days in an orbit that is much lower than the ISS, up to 100NM lower. That's why you get a differential nodal regression between those two orbits. Effectively you need to insert the Shuttle in an orbit that has a Longitude of the Ascending Node (LAN) that is further east. Then it's going to be pushed westwards, more than the ISS. In the case of STS-114 the orbits in this post OMS-2 scenario are:

Shuttle:
Inclination: 51.66°
LAN: 59.28°

ISS:
Inclination 51.66°
LAN: 58.85°

Both LAN values will become lower over time (so more towards west) and when the Shuttle is finally doing the maneuvers that takes it "up" to the ISS orbit the LAN values will be almost identical.