SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

Is there a clean solution possible? Like updating the texture and allowing maybe different cue cards?

 

[GLS]

Is there a clean solution possible? Like updating the texture and allowing maybe different cue cards?

I just checked and there is one card for Ascent with the throttle scales, and another for Landing with the speedbrake %... as we don't have card/checklist display capability, that will have to wait.
Just the animation is already a good improvement: the SBTC has a motion range of 60º, I tested it already (moving half of the vc with it :shifty and IMO it's already a good indication of it is doing, certainly better that having nothing. :shrug:

 

[Urwumpe]

Well, it should better be bug free of course.

Also I think that adding cue cards to SSU would not be the worst idea to make it easier to use it...

 

[DaveS]

Checked in an updated VC mesh where the SBTCs have been separated into their own mesh groups.

 

[GLS]

Well, it should better be bug free of course.

So far it works well... if it doesn't, there's tons of time to fix it as this is for 5.0 and we haven't even released 4.0...

Also I think that adding cue cards to SSU would not be the worst idea to make it easier to use it...

No it wouldn't, but getting the SSUWorkbench to create/change scenarios would probably make things "more easier" for users.

---------- Post added at 03:27 PM ---------- Previous post was at 02:56 PM ----------

New stuff is up! Please play with it, especially the PCT stuff as it uses the SPD BK/THROT PBI, and that has now changed to a "dumb" button.
The only "eyebrow PBI" missing this correction is the BODY FLAP PBI... have to research the BF a bit before touching that one.

BTW: here's the "key map" for the RPTA and SBTC. The SBTC takeover switch is labeled per the Orbiter key consts, but it might not be that in the keyboard... for me it turns out to be the " ' " key... :uhh:

---------- Post added at 04:35 PM ---------- Previous post was at 03:27 PM ----------

I "plugged back in" the auto rudder command when in manual control, and the auto and man commands are now added together to keep the vehicle stable when in manual, but still allowing the user to control the rudder... somewhat.

So, is the Antelope Valley pack really a SSU requirement now? If so, then we can delete our EDW surface "stuff" from the repository.

 

[Urwumpe]

So, is the Antelope Valley pack really a SSU requirement now? If so, then we can delete our EDW surface "stuff" from the repository.

For 5.0 yes, I would say.

 

[GLS]

I checked my library and I actually have the 2005 version of that document*, but it's pretty much the same text. It seems that the SPI always displays the auto command, and the HUD displays the current command regardless of the source.
IMO, it makes sense to display actual command in the HUD, as the point is to not have to look anywhere else when using the HUD, so when in MAN, one doesn't have to look down at the SBTC to see what the command is. But at the same time, a display showing what guidance wants is also important (SPI).
If it's not this way, I can tolerate one angry post from a shuttle astronaut or technician. :lol:

BTW: any news on the SBTC mesh separation? I'm pretty much finished with the new logic...

*) we can always trade versions

https://sourceforge.net/projects/shuttleultra/files/References/Approach%2C%20Landing%20and%20Rollout%20Flight%20Procedures%20Handbook%20-%20Revision%20B%20-%20May%202005%20-%20Mission%20Operations%20Directorate%20Flight%20Design%20and%20Dynamics%20Division%20Ascent_Descent%20Dynamics%20Branch.pdf/download

 

[GLS]

Heads up when updating to r2553 in the beta branch: I'm removing the EDW surface files (as we now use the Antelope Valley scenery pack) and this will almost certainly delete some of the files from that pack, so it may need to be reinstalled.
I'm also removing the Textures2 folder from source control as we don't need it, and this may also delete the Orbiter files inside. :facepalm:

 

[Urwumpe]

Heads up when updating to r2553 in the beta branch: I'm removing the EDW surface files (as we now use the Antelope Valley scenery pack) and this will almost certainly delete some of the files from that pack, so it may need to be reinstalled.
I'm also removing the Textures2 folder from source control as we don't need it, and this may also delete the Orbiter files inside. :facepalm:

What about the following suggestion: We compile SSU outside an Orbiter directory and simply test by either using a ZIP file generated by the build process or by copying the final artifacts into an Orbiter installation for testing?

This way we could also easier integrate support for a possible Orbiter 2016 patch, since we no longer need to put a full Orbiter installation into our workspace. And we could better check, if a file will be missing from the release packages.

I already have a prototype solution on my private notebook using CMake and an earlier variant using VC solution files and batch scripts. But those are much simpler projects than our huge SSU.

I see some advantages there, but I suspect, I am the only person with some CMake experience here.

 

[GLS]

What about the following suggestion: We compile SSU outside an Orbiter directory and simply test by either using a ZIP file generated by the build process or by copying the final artifacts into an Orbiter installation for testing?

This way we could also easier integrate support for a possible Orbiter 2016 patch, since we no longer need to put a full Orbiter installation into our workspace. And we could better check, if a file will be missing from the release packages.

I already have a prototype solution on my private notebook using CMake and an earlier variant using VC solution files and batch scripts. But those are much simpler projects than our huge SSU.

I see some advantages there, but I suspect, I am the only person with some CMake experience here.

Separating the instalations and then copying stuff would add a few more seconds (at least) to each "compile&run cycle"... when running Orbiter maybe 30 times a day, those seconds will add up. I think it's a rare occurence that we have these kind of colisions with Orbiter files. (BTW: on my end it didn't delete anything)

As for missing files in our release package, if we delete a file and don't delete it from the release list, it will signal that it can't find file x. To catch new files that weren't added to the release list, it's just a question of opening the svn log and looking for revisions that added new stuff. IMO this on is controlled.

On the CMake, if it realy makes us have just one set of project files, and we can then navigate as is on VS, whatever the version, I'm all for that. But if it takes away the "project POV" on VS (stuff like "go to declaration", etc), and it becomes just a simple text editor, then I think it will slow things down...

 

[Urwumpe]

On the CMake, if it realy makes us have just one set of project files, and we can then navigate as is on VS, whatever the version, I'm all for that. But if it takes away the "project POV" on VS (stuff like "go to declaration", etc), and it becomes just a simple text editor, then I think it will slow things down...

It generates VS files for any VS version you have installed, which is good because it also fixes the version conflicts we have.

Also: I see no problem with the second more for synchronizing DLLs or 3 seconds more for synchronizing meshes and textures. It should actually save time.

 

[GLS]

It generates VS files for any VS version you have installed, which is good because it also fixes the version conflicts we have.

That's good.

Also: I see no problem with the second more for synchronizing DLLs or 3 seconds more for synchronizing meshes and textures. It should actually save time.

How does it save time?

 

[Urwumpe]

How does it save time?

For example: Time for fixing bugs in the release packages because something was missing. Or something was not properly checked in. Or having a wrong path somewhere.

Or by being able to test multiple different configurations with a single workspace.

 

[GLS]

For example: Time for fixing bugs in the release packages because something was missing. Or something was not properly checked in. Or having a wrong path somewhere.

IMO that is controlled enough since the introduction of the release file list.

Or by being able to test multiple different configurations with a single workspace.

"multiple different configurations" as in Orbiter versions? (For different SSU branches there would be no difference, one would still have to switch the working copy...) :S
I'm sorry but I don't see gains in this separation.

 

[Urwumpe]

"multiple different configurations" as in Orbiter versions? (For different SSU branches there would be no difference, one would still have to switch the working copy...) :S
I'm sorry but I don't see gains in this separation.

For example, what kind of configurations SSU faces in the real world after we released it:

With patch - without patch
with OrbiterSound - without Orbitersound
With DX7 - with DX9
With UMMU - No UMMU, etc.

 

[GLS]

For example, what kind of configurations SSU faces in the real world after we released it:

With patch - without patch
with OrbiterSound - without Orbitersound
With DX7 - with DX9
With UMMU - No UMMU, etc.

You need different Orbiter instalations for that, and with the release script we are just 2 clicks away from creating a package, that can then be extracted into those instalations.
Yeah, this could all be automated a little bit, but it seems like more pain than gain.... :shrug:

 

[GLS]

I'm thinking about pushing our GPC (software) architecture a bit further by introducing the "User Parameter Processing" to act as a source of data (altitude, speed, etc) to the GPC software, and a "poor man's COMPOOL" to share that data. This way I think I can make the transition between "altitude above sea level" during MM304 and "altitude above the runway" for MM305, hopefully solving the runway altitude issue.

About the UPP my doubt is on whether to have one class for all phases of flight, or several smaller classes, one for each phase. On the "cheap COMPOOL", should the variables/array/whatever be inside the SimpleGPCSystem, or should it be another SimpleGPCSoftware derived class?

 

[Urwumpe]

I'm thinking about pushing our GPC (software) architecture a bit further by introducing the "User Parameter Processing" to act as a source of data (altitude, speed, etc) to the GPC software, and a "poor man's COMPOOL" to share that data. This way I think I can make the transition between "altitude above sea level" during MM304 and "altitude above the runway" for MM305, hopefully solving the runway altitude issue.

About the UPP my doubt is on whether to have one class for all phases of flight, or several smaller classes, one for each phase. On the "cheap COMPOOL", should the variables/array/whatever be inside the SimpleGPCSystem, or should it be another SimpleGPCSoftware derived class?

Well, I would use a struct for the COMPOOL I think and leave it to the software to interpret what it is. Maybe just have an array of COMPOOL pointers for a major function/major mode to simplify the addressing (In the real system, this would be done during compilation, it had a very simple memory management)

That is actually the pretty simple part of it all. For the IO, what about using a DAO-like class as abstraction layer?

The final state that I plan for is having IO programs, that are essentially used with a simple I/O interface in the sense of the following SVC function:

svc_start_io(CCW& command_word)

with the CCW containing where to find the IO program instructions.

I am writing this from a hotel room, so don't expect too much detail from me. I know from comparisons at home, that the CCW is very similar to the standard System/360 CCW, but has some small important differences.

For getting the User Parameters that you talk about into SSU, I would suggest the following plan:

1. In the scenario file, you specify a "ILOAD file" (Initial load, that is how the constants are called that are written on the magnetic tape before launch)

2. In SSU, a ILOAD linker class is called. This linker is specific for the GPC model we use and sets the constants as we need them.

2.1 The ILOAD linker should react to events:
2.1.1 OnInit to set constants that are independent of the flight phase
2.1.2 OnMFOrMMChange to set constants when the major function or major mode changes. This is also called at scenario start when the saved MF/MM is restored.
2.2 The file format for the ILOAD file should be the same for all GPC models we will ever use.
2.3 The ILOAD linker should be capable of being called anytime even during runtime of a scenario. This should allow us later to configure a landed Orbiter for a new launch.

Now back some step about how the software for the real shuttle was prepared, see page 31 here:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100028293.pdf

The role of the SM Preprocessor and Auto I-Load processor would be our SSU Workbench (or a command line tool written in C++ that is called by our Workbench, if you are as weird as I am and like to be able to do such steps manually). After the Return to Flight, two new more capable software tools replaced those STAR and MAST. STAR did the tasks of I-Load processor and SM preprocessor, MAST generated TFL (telemetry format list), DFL (display format list) and FPL (Fetch Pointer Load*).


Thus, I would suggest using the HAL/S COMPOOL data declaration syntax there for the constants. It would take a bit longer to parse and to write such a parser, but it would be easier to validate against the NASA documents we already have.

The partition based model I plan for would only use OnInit... I would write the ILOAD into the tape drive image and later load the whole data into the needed ZCON memory areas. For that, I only need to know for the linker, which COMPOOL definition files are getting loaded into which memory overlay at which address. I want to get towards some sort of AET compilation for each mission software, combining HAL/S data structures with C++ compilation units, so we can use the best of both worlds.

Just as a head up: NASA awarded an excellence award in 1986 for more than halving the time for flight software configuration.... from 11 weeks to 5 weeks. I am sure, we can do this faster eventually.

* Fetch Pointers are used for collecting telemetry data from the various OI subsystems. I found the definition here in this SPOC:

https://www.nasa.gov/centers/johnson/doc/175304main_Conformed_SPOC_NNJ06VA01C_32007.doc

The contractor shall maintain the Measurement and Stimuli (MAST) II database including definition and incorporation of hardware component calibration coefficients and curves, measurement channelization, and telemetry format requirements in accordance with current baseline process SCR 89053-MAST II/STAR Reconfiguration. The contractor shall resolve payload data interleaver compiler bandwidth and instruction issues. The contractor shall provide a “help desk” capability to facilitate user interaction (DR 1.4.3.1-k, DR 1.4.3.1-n, and DR 1.4.3.1-q).

The contractor shall perform functional compatibility analyses of the DPS hardware, systems software and avionics interfaces to verify that proper fault tolerance requirements are satisfied and that proper compatibility exists. The contractor shall establish/evaluate the requirements for the DPS software including Flight Computer Operating System (FCOS), User Interface (UI), Systems Control (SC), redundancy management, and generic Uplink (UL) for proper control and performance of the DPS. The contractor shall perform integrated DPS-related systems assessments, and present recommendations for preflight/flight/post-flight technical issues, anomalies, and problems potentially affecting flight readiness, flight safety, or mission success (DR 1.2.1.7-a).

The contractor shall be responsible for coordinating the technical content of vehicle DCRs and mission I-Loads and will load the STAR/MAST systems with data in support of JSC’s Engineering Directorate. The contractor will coordinate these data entries at the SASCB and/or the SASCB Shuttle Data Control Boards (SDCBs) for DCRs affecting engineering accountable hardware subsystems and I-Loads (DR 1.4.3.3-x).

The contractor shall provide the I-load baseline and coordination support in order to provide I-load inputs into the Flight Software Reconfiguration Process.

Sounds like the kind of tool we will need one day.

 

[GLS]

Well, I would use a struct for the COMPOOL I think and leave it to the software to interpret what it is. Maybe just have an array of COMPOOL pointers for a major function/major mode to simplify the addressing (In the real system, this would be done during compilation, it had a very simple memory management)

That is actually the pretty simple part of it all. For the IO, what about using a DAO-like class as abstraction layer?

The final state that I plan for is having IO programs, that are essentially used with a simple I/O interface in the sense of the following SVC function:

svc_start_io(CCW& command_word)

with the CCW containing where to find the IO program instructions.

I am writing this from a hotel room, so don't expect too much detail from me. I know from comparisons at home, that the CCW is very similar to the standard System/360 CCW, but has some small important differences.

For getting the User Parameters that you talk about into SSU, I would suggest the following plan:

1. In the scenario file, you specify a "ILOAD file" (Initial load, that is how the constants are called that are written on the magnetic tape before launch)

2. In SSU, a ILOAD linker class is called. This linker is specific for the GPC model we use and sets the constants as we need them.

2.1 The ILOAD linker should react to events:
2.1.1 OnInit to set constants that are independent of the flight phase
2.1.2 OnMFOrMMChange to set constants when the major function or major mode changes. This is also called at scenario start when the saved MF/MM is restored.
2.2 The file format for the ILOAD file should be the same for all GPC models we will ever use.
2.3 The ILOAD linker should be capable of being called anytime even during runtime of a scenario. This should allow us later to configure a landed Orbiter for a new launch.

Now back some step about how the software for the real shuttle was prepared, see page 31 here:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100028293.pdf

The role of the SM Preprocessor and Auto I-Load processor would be our SSU Workbench (or a command line tool written in C++ that is called by our Workbench, if you are as weird as I am and like to be able to do such steps manually). After the Return to Flight, two new more capable software tools replaced those STAR and MAST. STAR did the tasks of I-Load processor and SM preprocessor, MAST generated TFL (telemetry format list), DFL (display format list) and FPL (Fetch Pointer Load*).


Thus, I would suggest using the HAL/S COMPOOL data declaration syntax there for the constants. It would take a bit longer to parse and to write such a parser, but it would be easier to validate against the NASA documents we already have.

The partition based model I plan for would only use OnInit... I would write the ILOAD into the tape drive image and later load the whole data into the needed ZCON memory areas. For that, I only need to know for the linker, which COMPOOL definition files are getting loaded into which memory overlay at which address. I want to get towards some sort of AET compilation for each mission software, combining HAL/S data structures with C++ compilation units, so we can use the best of both worlds.

Just as a head up: NASA awarded an excellence award in 1986 for more than halving the time for flight software configuration.... from 11 weeks to 5 weeks. I am sure, we can do this faster eventually.

* Fetch Pointers are used for collecting telemetry data from the various OI subsystems. I found the definition here in this SPOC:

https://www.nasa.gov/centers/johnson/doc/175304main_Conformed_SPOC_NNJ06VA01C_32007.doc





Sounds like the kind of tool we will need one day.

I've read this once and I'm still digesting it all.... give me a couple of weeks :lol::facepalm:
Anyway, I think you are mixing the UPP with ILOADS, which AFAIK don't have anything to do with each other. The UPP is the module (or whatever it is) that updates the state vectors and other parameters used by the rest of the software and the displays: altitude, relative speed, inertial speed, attitude, alpha, acceleration, etc. IMO the name doesn't quite match the function, but then and again, naming is not an easy part of programming... :shrug:

 

[Urwumpe]

I've read this once and I'm still digesting it all.... give me a couple of weeks :lol::facepalm:
Anyway, I think you are mixing the UPP with ILOADS, which AFAIK don't have anything to do with each other. The UPP is the module (or whatever it is) that updates the state vectors and other parameters used by the rest of the software and the displays: altitude, relative speed, inertial speed, attitude, alpha, acceleration, etc. IMO the name doesn't quite match the function, but then and again, naming is not an easy part of programming... :shrug:

Well, practically, this software is a repeated task of the GNC PASS. It takes data from the various sources and performs a Kalman filter on it before writing it into the GNC COMPOOL. I am sure I can find the true name of it in one of the compiler listings I have found.

And the input data for this task is provided by the GNC Sensor RM task again in the GNC COMPOOL.

I thought you are talking about the I-Loads for the runway data.

---------- Post added at 09:17 AM ---------- Previous post was at 09:11 AM ----------

About the mesh errors discovered by Donamy: Can't we just do a pre-release and wait at least a week before releasing should nothing need to be fixed?

I think the errors we discover right now are not necessary, we could have found them before release.