SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Hi there,

in the latest nightly (r2244) the "check for 90% thrust" was disabled -thanks for that- but
I was thinking I could make this behavior configurable and searched the source. But I coul not find anything like "config" there.

Am I right that there is no generic SSU-Config where something like this could be placed?

...
[RSLS]
CHECK_SSME_90_PERCENT=true ; enable / disable T-2s SSME PC>=90% check (it may cause aborts when frame rate is low)
...

And if there is no general SSU-Config, why is that so?

/Kuddel

Such stuff goes into the SpaceShuttleUltra.cfg, which is parsed in clbkSetClassCaps.

You are right, we have no central configuration class or structure. Not sure if we really need one now, but I like your idea. :lol:

 

[GLS]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

 

[DaveS]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

Disabling red-line limits monitored by the GLS is the sole responsibility of the GLS console operator, callsign CGLS. This is after a GO given by the NTD. CGLS can even inhibit/override the SRO "hold-fire" if required.

The NTD is the absolute top-level of the launch/test team, everyone including Houston FLIGHT, reports to the NTD. The only one higher is the Launch Director, callsign LD. In fact, the LD is so high that not even the chair of the MMT can override the LD. As long as the vehicle is bolted to the MLP, it belongs to KSC. JSC gets to "borrow" it for a weeks but as soon as GSE cooling is initiated post-landing it returns to KSC and the one actually flipping switches and reconfiguring the GPCs is a KSC Spacecraft Operator or SCO who is specially trained KSC Orbiter tech. The callsign of the SCO is CDR.

 

[Urwumpe]

About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

Can be done, still glitching around the MFD bugs.

---------- Post added at 11:12 PM ---------- Previous post was at 11:06 PM ----------

This is how the MFDs look like after saving the above mix of CRT and MEDS displays.

BEGIN_MFD Left
  TYPE User
  MODE CRT
  Mode2 1
  Display 2
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE CRT
  Mode2 2
  Display 5
END_MFD

BEGIN_MFD 5
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 6
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 7
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 8
  TYPE User
  MODE CRT
  Mode2 2
  Display 3
END_MFD

BEGIN_MFD 9
  TYPE User
  MODE CRT
  Mode2 2
  Display 4
END_MFD

That was even before I switched position, so the problem is somewhere internal to the CRT MFD.

---------- Post added at 11:26 PM ---------- Previous post was at 11:12 PM ----------

Interesting.... when I load and save the scenario, it works.

It works even so good, when I quit Orbiter and start "Atlantis in Orbit" again, so all MDUs are offline, turning the MDUs on and switching from Orbit MFD to CRT MFD results in all MDUs having the configuration, which I last saved in another scenario.

Looks like a non-initialized memory glitch.

---------- Post added at 11:35 PM ---------- Previous post was at 11:26 PM ----------

Bug fixed now... question to the other devs, are you using debug mode or release mode for compiling SSU? I only use debug mode when using breakpoints.

 

[DaveS]

I exclusively use Release mode when compiling.

 

[Urwumpe]

Found the bug in the runway drawing code:

rwy_pos_x[i] = hps->CX + static_cast<int>( Round(hps->Scale*DEG*atan(error[i].x/error[i].z)) );
rwy_pos_y[i] = hps->CY + static_cast<int>( Round(hps->Scale*DEG*atan(-error[i].y/error[i].z)) );

Who calls atan, gets atan. Instead of atan2 or a proper projection using only linear algebra instead of trigonometry

3.0 RC1 is on the server now, tomorrow I will look at making a better projection of the runway

 

[GLS]

About 95% debug. Occasionally I go to release to see if anything (bad) happens, as the structure is different. I also play with the compiler settings. So far didn't find anything different between them.

 

[Urwumpe]

About 95% debug. Occasionally I go to release to see if anything (bad) happens, as the structure is different. I also play with the compiler settings. So far didn't find anything different between them.

Its important because debug mode does initialize the memory with a control pattern, release does not.

 

[kuddel]

Such stuff goes into the SpaceShuttleUltra.cfg, which is parsed in clbkSetClassCaps.

You are right, we have no central configuration class or structure. Not sure if we really need one now, but I like your idea. :lol:

SpaceShuttleUltra.cfg! I missed that one :facepalm:
Thanks for the quick response.

 

[Urwumpe]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

I think that for performance and stability reasons, we should be able to either:

Disable certain checks or
Reduce the sensitivity of the checks


so they are stable even at low FPS. And that independent of any in-game feature like a LCC.

---------- Post added at 12:35 AM ---------- Previous post was at 12:12 AM ----------

Increased the RCS PRI RATE default value to 2.0°/s instead of 0.2°/s, which is the absolute minimum legal entry to ORBIT DAP.

As future improvement, we should create a clone of OrbitDAP and merge it into TransitionDAP, instead of letting OrbitDAP handle Rotations and Translations in OPS 104-106

 

[SiameseCat]

A default RCS PRI RATE of 2.0 deg/s is way too high. Looking at the DAP tables for STS-134 (https://www.nasa.gov/centers/johnson/pdf/539927main_ORB_OPS_134_F_A_1.pdf), the PRI ROT RATE is usually 0.2 deg/s, or less, with the maximum value being 0.5 deg/s.

 

[Urwumpe]

A default RCS PRI RATE of 2.0 deg/s is way too high. Looking at the DAP tables for STS-134 (https://www.nasa.gov/centers/johnson/pdf/539927main_ORB_OPS_134_F_A_1.pdf), the PRI ROT RATE is usually 0.2 deg/s, or less, with the maximum value being 0.5 deg/s.

Those are on-orbit, not transition. I know that 2.0°/s is likely pretty high, even half of it would appear fast - but the pitch down for ET photography is at 2.0°/s according to the ASCENT CL, that is the value that I used for reference.

The problem is just: At 0.2°/s, a 180° maneuver would take just 900 seconds or 15 minutes. We need about 24 minutes for getting from MECO attitude to OMS-1 attitude.

And as another problem: Attitude hold does not work in OPS 104, the propellant dump makes the Shuttle tumble.

---------- Post added at 10:09 AM ---------- Previous post was at 09:48 AM ----------

Another theory, that I have not yet checked... are we in VERN mode in some scenarios? In the big one, it does not matter because VERN is not supported by Transition DAP (like many other DAP modes)

 

[GLS]

Those are on-orbit, not transition. I know that 2.0°/s is likely pretty high, even half of it would appear fast - but the pitch down for ET photography is at 2.0°/s according to the ASCENT CL, that is the value that I used for reference.

The problem is just: At 0.2°/s, a 180° maneuver would take just 900 seconds or 15 minutes. We need about 24 minutes for getting from MECO attitude to OMS-1 attitude.

And as another problem: Attitude hold does not work in OPS 104, the propellant dump makes the Shuttle tumble.

---------- Post added at 10:09 AM ---------- Previous post was at 09:48 AM ----------

Another theory, that I have not yet checked... are we in VERN mode in some scenarios? In the big one, it does not matter because VERN is not supported by Transition DAP (like many other DAP modes)

Can't the OMS-1 be heads-down? (or heads-up if it is like that at MECO) If I need to do an OMS-1, I hit "ITEM 5 + 180" and then it just needs to pitch 10º or so. In reality this would be part of the default targets.
I don't know the rates or attitude deadbands, but there is some yaw that builds in after MECO (caused by the LH2 dump), judging by the screens in the MCC in pre STS-107 flights.
For the ET photo pitch up, the crew would change modes in the OrbitDAP PBs (I don't remember what exactly, but there's a procedure somewhere) and the pitch caused by the LOX dump would be enough to turn around.

 

[Urwumpe]

The roll attitude is not the problem, but the pointing of the thrust axis. The whole attitude hold after MECO fails right now.

I still need to analyze the exact error sources there, why we are terribly off. I suspect that missing ILOADs is just one factor out of many there.


You can be sure in one factor: Right now, we test after a launch scenario, by following the ASCENT CL. But in our quick & really dirty DPS implementation, we use the Orbit DAP and not the correct Transition DAP, which behaves significant different.

(Our "Transition DAP" wrongly does the Z translation after ET separation, instead it would be responsible for turning manual and automatic rotation and translation commands into RCS firings. The Z-translation is commanded by the ET SEP process)

So, part of our quality assurance for this release should be making sure, that the orbit DAP push buttons and orbit DAP configuration data are set in a way, that the differences to the transition DAP are minimal.

EDIT: Also for the photography, the DAP pushbuttons for the pitch channel are moded from DISC to PULSE, YAW and ROLL are keeping zero rates in the selected navigation frame INRTL. Rotation should be between 2°/s and 3°/s. After Dump is complete, Pitch is moded back to DISC for continuing the maneuver. PULSE just provides a way to reduce the rotation rates by directly firing the active pitch down thrusters in a single pulse by moving the RHC forward.

 

[GLS]

The roll attitude is not the problem, but the pointing of the thrust axis. The whole attitude hold after MECO fails right now.

I still need to analyze the exact error sources there, why we are terribly off. I suspect that missing ILOADs is just one factor out of many there.


You can be sure in one factor: Right now, we test after a launch scenario, by following the ASCENT CL. But in our quick & really dirty DPS implementation, we use the Orbit DAP and not the correct Transition DAP, which behaves significant different.

(Our "Transition DAP" wrongly does the Z translation after ET separation, instead it would be responsible for turning manual and automatic rotation and translation commands into RCS firings. The Z-translation is commanded by the ET SEP process)

So, part of our quality assurance for this release should be making sure, that the orbit DAP push buttons and orbit DAP configuration data are set in a way, that the differences to the transition DAP are minimal.

EDIT: Also for the photography, the DAP pushbuttons for the pitch channel are moded from DISC to PULSE, YAW and ROLL are keeping zero rates in the selected navigation frame INRTL. Rotation should be between 2°/s and 3°/s. After Dump is complete, Pitch is moded back to DISC for continuing the maneuver. PULSE just provides a way to reduce the rotation rates by directly firing the active pitch down thrusters in a single pulse by moving the RHC forward.

I created the TransDAP and got it to do the Z-translation, and then I looked inside the OrbitDAP and got too scared to add anything else :facepalm:.
About the Z-translation: the command goes from the ET SEP Sequence to ASC RCS CMD SOP and TransDAP. If it is started by the ET SEP Sequence and then terminated by the TransDAP, I don't know, but the TransDAP is in it somehow.

 

[Urwumpe]

I created the TransDAP and got it to do the Z-translation, and then I looked inside the OrbitDAP and got too scared to add anything else :facepalm:.

I know. Part of our software development problem is, that we create too large classes with too large functions and too complex functions even for simple problems, because we overload them with functions that they never had in the real one.

Its just like Ascent DAP or RSLS also being responsible for handling display inputs or AerojetDAP painting the HUD (Actually, the controlling GPC only provide the navigation data to the HUD - the HUDs paint themselves). Its not just stupid from our own side to make our own life that hard. The software developers of the big one have also never done that, despite all pressure regarding the slow first generation AP-101s and the limited memory.

In the big one, the UI of the application software and the sequencing of the related tasks below the UI is done by special programs called "control segments", which are mostly made of HAL/S macro commands. All a lot more standardized and all a lot smaller than our code.

About the Z-translation: the command goes from the ET SEP Sequence to ASC RCS CMD SOP and TransDAP. If it is started by the ET SEP Sequence and then terminated by the TransDAP, I don't know, but the TransDAP is in it somehow.

I would need to look for the exact sequence again. I know that the TransDAP is responsible for executing the translation command, but I am not sure if the TransDAP also controls the 4 fps velocity change in Z. I would not be surprised if another process is active for that. During OPS1, there is for example also one process for IMU navigation and SuperG integration (velocity change!) active in the background.

About the differences between SuperG and various other tested functions, here is a 1979 NASA tech doc about it: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19800018906.pdf

 

[GLS]

I know. Part of our software development problem is, that we create too large classes with too large functions and too complex functions even for simple problems, because we overload them with functions that they never had in the real one.

Its just like Ascent DAP or RSLS also being responsible for handling display inputs or AerojetDAP painting the HUD (Actually, the controlling GPC only provide the navigation data to the HUD - the HUDs paint themselves). Its not just stupid from our own side to make our own life that hard. The software developers of the big one have also never done that, despite all pressure regarding the slow first generation AP-101s and the limited memory.

In the big one, the UI of the application software and the sequencing of the related tasks below the UI is done by special programs called "control segments", which are mostly made of HAL/S macro commands. All a lot more standardized and all a lot smaller than our code.

On the display/HUD painting, the shared memory pool will help in making data available for that, making it easier to move the displays out of the SW classes.
I thing we have to do, it will probably hurt but should be done, is separating the FCS from guidance (both on ascent and entry), so we can go MAN and still keep the guidance outputting to the ADI needles.

I would need to look for the exact sequence again. I know that the TransDAP is responsible for executing the translation command, but I am not sure if the TransDAP also controls the 4 fps velocity change in Z. I would not be surprised if another process is active for that. During OPS1, there is for example also one process for IMU navigation and SuperG integration (velocity change!) active in the background.

In the diagram I have, the ET SEP Sequence just sends that command, it doesn't do anything related to stopping the Z-translation.

 

[Urwumpe]

I thing we have to do, it will probably hurt but should be done, is separating the FCS from guidance (both on ascent and entry), so we can go MAN and still keep the guidance outputting to the ADI needles.

Might be not too hard, if we follow some layering there. Remember, one process should in the ideal case just have one responsibility. In the real shuttle software, the number of processes was limited, so this coercion criteria was softened towards just minimizing the number of responsibilities.

In the diagram I have, the ET SEP Sequence just sends that command, it doesn't do anything related to stopping the Z-translation.

That should be correct. As far as I can tell about the HAL/S FC programming used in the shuttle, there are no commands that are send around inside the GPC software. You actually set/reset special 16 bit event variables.

In the case of the ET separation, this would mean: The ET SEP process and the "translation process" had been started as software at the same time, but the "translation process" goes into a WAIT state for the event flag "all connections to the ET separated" - FCOS now checks during every process switching event, if the variable that the translation process waits for has been set. When the ET SEP process has done its job, it sets this flag and the translation process can resume execution. The process management of FCOS does a lot of magic, its quite interesting.

Now the problem is just: How to tell that 4 fps in Z have been reached? Such a problem is exactly what the SuperG integration should solve, so I would expect that it is used there, just like it would be used for OMS maneuvers in OPS1 or OMS/RCS maneuver in OPS2.

 

[GLS]

My data comes from this 3 NTRS docs: 19800073367_1980073367, 19810072044_1981072044 and 19820066528_1982066528 (not sure if they are still available).

Changing subject: is there a way of having control over what vessel attaches at a certain attachment? It would be nice to have just the IUS attach to the ASE and the Centaur G to the CISS G, etc. I though the the "id" string was for that ("The identifier string can contain up to 8 characters. It can be used to define compatibility between attachment points.") but it doesn't seem to work.... does it need "active" checking?

 

[Urwumpe]

does it need "active" checking?

Yes, attachments are fully user-defined in their run-time behavior - you can have a IUS at ANY other attachment in the scenario file, if you want it so.

---------- Post added at 02:51 PM ---------- Previous post was at 02:44 PM ----------

My data comes from this 3 NTRS docs: 19800073367_1980073367, 19810072044_1981072044 and 19820066528_1982066528 (not sure if they are still available).

Short check: No.