SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
Thanks Don :thumbup:
Donamy
Addon Developer
GLS
Well-known member
I'd like to finish the HUD overlays once and for all, and (I think) I've made some progress but it still isn't right.
I separated the logic for points and for lines. Points in front of the HUD are easy to place, points behind the HUD aren't draw. Lines... that's where things get tricky: both ends in front are easy, and if both are behind then it isn't drawn. When one end of the line is in front and the other is behind, the point behind is projected onto the HUD plane, and that new point replaces the one behind. The problem is now finding where this new point is in the HUD display.
That was/is calculated by getting the angle between the boresight and point, plus a "clock angle" and the X and Y angles from the boresight would be obtained, multiply by the current HUD scale et voilá!
This logic fails as the point in now contained in the plane, so the angle to the normal is always 90º, so I can't tell how far from the boresight it is... :facepalm:
Any ideas on getting these overlays working properly?
BTW: it currently is much better than it was, the runway doesn't flip up like it did... it just isn't where it should. :shrug:
I separated the logic for points and for lines. Points in front of the HUD are easy to place, points behind the HUD aren't draw. Lines... that's where things get tricky: both ends in front are easy, and if both are behind then it isn't drawn. When one end of the line is in front and the other is behind, the point behind is projected onto the HUD plane, and that new point replaces the one behind. The problem is now finding where this new point is in the HUD display.
That was/is calculated by getting the angle between the boresight and point, plus a "clock angle" and the X and Y angles from the boresight would be obtained, multiply by the current HUD scale et voilá!
This logic fails as the point in now contained in the plane, so the angle to the normal is always 90º, so I can't tell how far from the boresight it is... :facepalm:
Any ideas on getting these overlays working properly?
BTW: it currently is much better than it was, the runway doesn't flip up like it did... it just isn't where it should. :shrug:
GLS
Well-known member
indy91
Addon Developer
- Joined
- Oct 26, 2011
- Messages
- 1,264
- Reaction score
- 727
- Points
- 128
Well, this is a general rendezvous planner, based on the Orbital Maneuver Processor (OMP, hence the name I chose for the MFD) that the Shuttle FDOs used (and definitely a descendant of tools used during Gemini/Apollo/Skylab/ASTP). The picture shows the the Maneuver Constraints Table to the left and the Maneuver Evaluation Table to the right. And I can already use the workflow in the FDO Console Handbook to fix TI lighting and reduce the TI DVZ component by adjusting the TIGs of previous maneuvers.
I bet the Shuttle computer supported PEG-7 DV uplinks, but that's just based on the fact that the AGC supported that. So why shouldn't the Shuttle? :lol:
I can implement the same thing I did for NASSP with my RTCC MFD, in this case select one of the maneuvers from the evaluation table, which are all impulsive burns, calculate a finite burn from it (earlier TIG, modified DV vector) and present it as a Maneuver PAD of sorts. I am recycling a lot from the RTCC MFD, so it's not that much work.
When I get this MFD into a more releasable state I'll put it on Github. Right now I'm testing a STS-126 rendezvous, just to see if the Shuttle actually ends up somewhere useful.
Also, have you noticed the NPC DV vector? 731 ft/s. That is without taking nonspherical gravity into account, with it taken into account it's even worse. Not quite sure why that is. STS-126 launched in the middle of their launch window, so the in-plane insertion that SSU currently supports shouldn't be so bad. Maybe the ISS state vector in the STS-126 scenario is off.
I bet the Shuttle computer supported PEG-7 DV uplinks, but that's just based on the fact that the AGC supported that. So why shouldn't the Shuttle? :lol:
I can implement the same thing I did for NASSP with my RTCC MFD, in this case select one of the maneuvers from the evaluation table, which are all impulsive burns, calculate a finite burn from it (earlier TIG, modified DV vector) and present it as a Maneuver PAD of sorts. I am recycling a lot from the RTCC MFD, so it's not that much work.
When I get this MFD into a more releasable state I'll put it on Github. Right now I'm testing a STS-126 rendezvous, just to see if the Shuttle actually ends up somewhere useful.
Also, have you noticed the NPC DV vector? 731 ft/s. That is without taking nonspherical gravity into account, with it taken into account it's even worse. Not quite sure why that is. STS-126 launched in the middle of their launch window, so the in-plane insertion that SSU currently supports shouldn't be so bad. Maybe the ISS state vector in the STS-126 scenario is off.
I think this might be of interest here: https://www.dropbox.com/s/ffu0vzkanzt1ebc/G&C I_O_D 21002.pdf?dl=0
GLS
Well-known member
As you know the Earth is a sphere in Orbiter, so that puts the launch pad at the wrong place in relation to the ISS plane, so that is one thing wrong.
About the ISS state vector, I'm not sure if it is correct... going to celestrack and getting the TLE would be a good idea. Another issue is the time... I think Orbiter doesn't use the "normal" time (whatever that might be :uhh
, so that's another factor to account for, both in the scenario/launch time, as well as in the ISS TLE conversion.Ground-up HST rendezvous is even worst because the launch pad is never co-planner with the HST orbit.
---------- Post added at 12:51 PM ---------- Previous post was at 12:44 PM ----------
Very interesting document, even just glancing at it. It will be very helpful when reworking the OrbitDAP... maybe by 2022... :shifty:
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I have a lab report here proving that I did not touch alcohol for the past 10 weeks. (Now, don't ask why I needed such a report in first place)
The worse effect on my software development is not touching any caffeine for the past 8 months.
Gingin
Active member
Hey guys, I was wondering how hard it would be to feed some missing parameters in spec 34 ( item 7 to 12 ) to have our relative position at T1 ignition.
That would be really useful as spec 34 is already a great help for complex rendez vous
That would be really useful as spec 34 is already a great help for complex rendez vous
indy91
Addon Developer
- Joined
- Oct 26, 2011
- Messages
- 1,264
- Reaction score
- 727
- Points
- 128
Hey guys, I was wondering how hard it would be to feed some missing parameters in spec 34 ( item 7 to 12 ) to have our relative position at T1 ignition.
That would be really useful as spec 34 is already a great help for complex rendez vous
I had looked for that in the past, pretty sure it's the routine REL_COMP from this document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790001906.pdf PDF pages 46-49. That just needs to be implemented.
GLS
Well-known member
Still working entry stuff, so I can only look at that when I'm done.
indy91, that document looks like a "gold mine", only after a quick look at it, thanks!
indy91, that document looks like a "gold mine", only after a quick look at it, thanks!
Gingin
Active member
Thanks for the return .
Another great document to add to the library
Another great document to add to the library
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
One question: Could this maybe be an option for adding mission control functions to SSU?
https://github.com/nasa/openmct
It is also already supported by KSP via a plugin, so it could well be suited for general Orbiter and SSU, I would say.
https://github.com/nasa/openmct
It is also already supported by KSP via a plugin, so it could well be suited for general Orbiter and SSU, I would say.
- Status
Similar threads
