Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 02-12-2019, 12:00 AM   #31
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by DaveS View Post
 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. 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.
Urwumpe is offline   Reply With Quote
Old 02-12-2019, 07:38 AM   #32
indy91
Addon Developer
Default

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.
indy91 is offline   Reply With Quote
Old 02-12-2019, 08:00 AM   #33
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

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.
Urwumpe is offline   Reply With Quote
Old 02-12-2019, 08:24 AM   #34
indy91
Addon Developer
Default

Quote:
Originally Posted by Urwumpe View Post
 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.
indy91 is offline   Reply With Quote
Old 02-12-2019, 08:58 AM   #35
GLS
Addon Developer
 
GLS's Avatar
Default

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.
GLS is online now   Reply With Quote
Old 02-12-2019, 09:16 AM   #36
indy91
Addon Developer
Default

Quote:
Originally Posted by GLS View Post
 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.
indy91 is offline   Reply With Quote
Old 02-12-2019, 09:21 AM   #37
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by indy91 View Post
  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.
GLS is online now   Reply With Quote
Thanked by:
Old 02-12-2019, 02:36 PM   #38
indy91
Addon Developer
Default

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.
indy91 is offline   Reply With Quote
Old 02-12-2019, 02:51 PM   #39
Wolf
Donator
 
Wolf's Avatar
Default

Quote:
Originally Posted by indy91 View Post
 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
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”)

Last edited by Wolf; 02-12-2019 at 02:53 PM.
Wolf is offline   Reply With Quote
Old 02-12-2019, 03:10 PM   #40
indy91
Addon Developer
Default

Quote:
Originally Posted by Wolf View Post
 That sounds very very promising
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.
indy91 is offline   Reply With Quote
Thanked by:
Old 02-12-2019, 06:04 PM   #41
Wolf
Donator
 
Wolf's Avatar
Default

Quote:
Originally Posted by indy91 View Post
 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.
Thanks for the clear explaination Indy
Wolf is offline   Reply With Quote
Old 02-13-2019, 01:53 PM   #42
Tim13
Orbinaut
Default

@Indy91 So right now, the Shuttle FDO MFD is scenario specific, as in real numbers from a real mission are the starting point?

Do you envision a time where a user could pick their own launch date/time, and the MFD would then look at the post MECO shuttle state, and the ISS state, and then do a real time calculation of all the burns based on the post shuttle launch data?

I find this MFD to be a very appealing idea to really enhance the immersion of the SSU.

Tim
Tim13 is offline   Reply With Quote
Old 02-13-2019, 02:50 PM   #43
indy91
Addon Developer
Default

Quote:
Originally Posted by Tim13 View Post
 @Indy91 So right now, the Shuttle FDO MFD is scenario specific, as in real numbers from a real mission are the starting point?

Do you envision a time where a user could pick their own launch date/time, and the MFD would then look at the post MECO shuttle state, and the ISS state, and then do a real time calculation of all the burns based on the post shuttle launch data?

I find this MFD to be a very appealing idea to really enhance the immersion of the SSU.

Tim
Right now it loads the launch time and rendezvous plan of STS-126 by default, because that's the mission I used for testing. But you can already change the time and every single thing about the rendezvous plan by hand. It's just a bit inconvenient to do that every time when loading Orbiter. So that will be improved. But in theory (minus bugs) you can already use the MFD with any mission you want and start planning your rendezvous some time between insertion and OMS-2. And it supports any burn after that, just need to delete the first maneuver in the plan whenever a burn was executed and adjust the constraints a bit.
indy91 is offline   Reply With Quote
Old 02-13-2019, 03:23 PM   #44
Donamy
Beta Tester


Default

Would this work for another ship ? The Crew Dragon perhaps.
Donamy is offline   Reply With Quote
Old 02-13-2019, 03:55 PM   #45
indy91
Addon Developer
Default

Quote:
Originally Posted by Donamy View Post
 Would this work for another ship ? The Crew Dragon perhaps.
The first two displays of the MFD, yes. Maneuver Constraints Table and Maneuver Evaluation Table are both using no Shuttle specific numbers for the calculation. The other displays that are already implemented are Shuttle specific, calculating burn times based on thruster selection etc. But you don't have to use those other displays. All you get in that case is the TIG and DV vector in LVLH coordinates based on an impulsive burn. Not sure how you would burn e.g. exactly 84.7 ft/s in a specific direction in the Crew Dragon though. Is there an MFD for that? In any case I will not add anything to the FDO MFD that would break the rendezvous planning part of it for other vehicles.
indy91 is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 02:37 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.