Space Shuttle Ultra development thread

[DaveS]

Sounds good to me for a release plan. That will buy me some time to get the MLP and FSS/RSS in order.

Goal for the next release could be complete simulation from flight crew ingress through OMS-2 burn.

 

[Urwumpe]

Sounds good to me for a release plan. That will buy me some time to get the MLP and FSS/RSS in order.

Goal for the next release could be complete simulation from flight crew ingress through OMS-2 burn.

Well, I think, that will take some more releases. I could spent a hour today defining the current and next work items, but I would need feedback to get this right.

My rough guestimate for playing the Ascent checklist without aborts:

1.20 is the current planned release (jump to a cuter number because of major changes justified)

1.21:
- GLS Simulation inside MLP. Communication with GPCs over launch data bus.
- MLP finally added as stable release.
- Full MPS simulation (Need feedback from GLS about how much worktime he would need from ignition to MPS dump. I think version 1.21 is possible)
- A few DPS fixes and DPS tied to related switches.
- DPS memory contains I-loads for OMS-1 and OMS-2, if OMS-2 is used. Store these I-loads in the fresh loaded GNC OPS memory overlay for each maneuver (Effect: When you switch from GNC OPS 104 "OMS-1 MNVR EXEC" to GNC OPS 105 "OMS-2 MNVR EXEC", you get the new I-Loads automatically loaded and displayed in the displays and only need to correct the values in the worst case later).

1.22
- Orbital DAP
- RCS Management
-- Begin developing a system to calculate CoG Shifts in the orbiter. No effect in Orbiter only calculating the position of the CoG relative to the reference position.

1.23
- Electrical Power subsystem (Major task, can need a long time)
-> Critical item are the essential buses, which are operated after crew ingress.
- FSS added.
- GLS gets moved into FSS implementation, communicates with Shuttle via MLP. GLS supports FSS animations.
- (Optional) include Mid deck mesh, if available. Long time for EPS might buy the visual artists the time to make two meshes for it. One is the low res version used for showing the mid deck through the side hatch window or open side hatch. The other the high res parts of the Mid-deck in VC mode.

1.24
- Add side hatch animation and Pole to shuttle, even when no full mid-deck is available yet. Instead use a dummy mid-deck then. Allow contigency aborts.
- Add side hatch cover to the side hatch when in prelaunch state.
- Develop the required panels and simulations for doing the communication checks. Only do commander comm check.

1.25 (unsure)
- Add ascent cue cards to the VCs?

Not scheduled yet:
- BFS software and BFC.
- Thermal control subsystem (Flash evaporators!)
- Life support subsystem


Any comments? I tried to keep the number of new features rather small, so we can keep our current habit of including new features just for fun. SSU developers just wanna have fun.

 

[SiameseCat]

The release plan looks fairly good to me. For the moment, I don't think it's necessary to be able progress manually to a new mission phase from a dialog.

For the VC, I think the best thing to do is to continue to use the existing CRT MFD framework. The other option would be to convert the three center displays from MFDs to use the MDU class. Either way, we'd have to add support for the SM OPS mode to support the payload bay attachment points.

SC

 

[Urwumpe]

I want to include this mission phase change feature only for debugging, but it could also be useful for abort transitions or other "soft" transitions.


Well, then at least use the MDU class for data storage, instead of having this double dependency with CRT. What the CRT MFD just needs to know is to display which data where (or how to turn formating information from the MDU class into rendering). Atlantis does not need to know the full rendering stuff of CRT currently as far as CRT does not need to know all internals of the Atlantis.


The MDM class is for connecting subsystems to the DPS (converts discrete and analog signals to Shuttle Bus protocol and back). Disabling one MDM means that you loose data to the GPCs. For example, the aft MDMs convert APU signals to digital data and format it for the GPCs, independent of the ADCs of MEDS or the primary Caution and Warning System.

Three letter acronyms are really annoying. Just change one letter and you have a whole different meaning. Can't they use German military style abbreviations, like "Mux/Demux" for the MDM or "MuFuDisp" for the MDU?

 

[Donamy]

Wondering what order the ODS retraction would take ? Also, is there a way to tie the CRT manuvering to the A2 panel for more precise docking.

 

[SiameseCat]

If we're going to use the MDU for data storage, we may as use it to display the data also. In that case, what we can do is leave the OMS, APU and SPI displays in CRT MFD, and move the GPC displays to the MDU. The 4 CRT displays with keyboards can be converted to use the MDUs.

 

[Urwumpe]

If we're going to use the MDU for data storage, we may as use it to display the data also. In that case, what we can do is leave the OMS, APU and SPI displays in CRT MFD, and move the GPC displays to the MDU. The 4 CRT displays with keyboards can be converted to use the MDUs.

I would say, we don't even need to go so far. The DPS displays are basically just a text terminal with vector drawing background, so, we can store the text data as array and leave it to the MFD how to render it.

The Keyboards should get tied to the four identical IDP implementations, which is only interested into the DPS display formating and input processing. The scratch pad lines are created by the IDP and are only send to the GPC when they have passed a basic syntax check. But I again think implementing the IDP can get delayed for later, as long as the keyboard input works again.

The IDP also takes GPC data and prints it into the MDU text buffers.

 

[Donamy]

I think we need a priorities list.

 

[SiameseCat]

I would say, we don't even need to go so far. The DPS displays are basically just a text terminal with vector drawing background, so, we can store the text data as array and leave it to the MFD how to render it.

How would we draw lines on the display then? Would this just be done by CRT MFD, or would the MDU store information about that too?

 

[Urwumpe]

I think we need a priorities list.

Yes. Do you want to make one? I just noticed that I missed the Caution and Warning System in my plannings, we should of course have this one at high priority.

How would we draw lines on the display then? Would this just be done by CRT MFD, or would the MDU store information about that too?

In reality, the IDP would provide drawing commands for primitive elements (lines, circles, rectangles, rotated text). I think we can do well with the CRT MFD doing this for a while, I don't feel like it helps the project to develop a full interface for drawing the background graphics inside MDU.

@All: What do you think about defining the VC animations inside a text file and loading it, instead of hard coding the data? I just noticed that defining one panel in the code will result in lots of repeated patterns, which could be defined inside a input file.

 

[SiameseCat]

I think we need a priorities list.

Here's my suggestion for a priority list:
For next release:
1. Payload management system. This includes the SM OPS mode.
2. Functioning keyboard input to MFDs. We should also remove the ITEM/SPEC/OPS buttons from CRT MFD. Required for payload management.
3. Mission definition files. Required for payload management.
4. ODS. We need to have a functioning docking port, but I can do without the ODS implementation for this release.
5. Mission management dialog. Useful, but not absolutely necessary.

For future releases:
1. DPS improvements. This will have to be done over several releases.
2. MPS simulation
3. GLS simulation.
4. GPC improvements. Tied to implementation of other subsystems.
4. Caution and warning system, once we have potential failures.
5. RCS control (selecting RCS jets and crossfeed between tanks).
6. Attitude control. This includes the Orbital DAP.
7. RMS simulation.
7. HUD
8. MEDS displays.

 

[Urwumpe]

Here's my suggestion for a priority list:
1. Payload management system. This includes the SM OPS mode.
2. Functioning keyboard input to MFDs. We should also remove the ITEM/SPEC/OPS buttons from CRT MFD. Required for payload management.
3. Mission definition files. Required for payload management.
4. ODS. We need to have a functioning docking port, but I can do without the ODS implementation for this release.
5. Mission management dialog. Useful, but not absolutely necessary.

My own votes:

1. Payload management system
2. Keyboard input to MFDs.
3. Mission definition files.
4. Mission Management dialog. I think its useful.
5. ODS + ODS Panels (ODS panels currently used by me for developing the VC code)
6. Primary Caution and Warning System. Needed at various places.
7. GPC code improvements (allow multitasking and in intervals active tasks, loading memory configs)
8. Star Trackers and Panel O6.

 

[DaveS]

I agree with Urwumpe's list. Would really like to see a good payload management system put in, while I also would like to see keyboard functionability return. Also, the return of the ODS is a good one.

 

[GLS]

Hi... sorry I've showed up lately (busy as hell)
Currently I'm cooking up the position of the valves for ignition and shutdown (3.5 of 5 now), and I'm searching for engine parameters (found a data for a Phase II engine, lots of good stuff). I'm still thinking about when the cmds and data will be done. I don't want something like you send a cmd for shutdown to the engine, and then get a data table (in the same frame) and it still reads MAINSTAGE.... I'm thinking of making SSME:: a son of EIU:: so that in EIU:: timestep calls the SSME:: timestep after it sends cmds, and before it gets data... (mental note: buy a board to draw all options)
Also a question about MPS dump, the MOV cmds come from the EIU or direcly from the GPC?

About the dates, a basic working system (ignition, throttle, shutdown, PC and vlv position data), would be some 1.5 - 3 weeks away. It depends on the data/cmd stuff. After that comes engine model, Purge Seq, more data (temps, rpms, press, vibs), watching for a dead Hyd or EPS to kill an engine, and that would be some time in the summer. (hope it isn't a slow enough pace for you to shoot me...) Another question, for the 104.5% throttle on recent engines, what do the GPCs tell the EIU: 104 or 104.5??? I'm asking because the engine is throttleable in 1% increments and so I don't know what to do with that .5%

and know I've to go to class... major chick in there... bye!

 

[Urwumpe]

GLS:

http://ssl.mit.edu/publications/theses/SM-1998-Lozano-TovarPaulo.pdf

I don't know a better source of information about the SSME behavior. It is damn math heavy, but I am sure, you will like it.

The Engine throttle commands can be in 1% increments, and the actual thrust increase still be 1.0001%. Commanded thrust is practically increasing Chamber pressure and a higher chamber pressure also increases specific impulse a bit.

 

[Donamy]

I would like to see the launch have everything, graphicaly correct.

1. T-4 engine gimble test
2. sparks for H2 burnoff
3. SSME step ignition, so you could watch it in 0.5X time.
4. correct roll pitch manuever
3. correct SRB cutoff and flame blowout.

At least as good as the Fleet does.

I know, this is all just eye candy, but it's what most people notice. All the other systems will work in after that.

 

[DaveS]

How's the cameras for the MLP coming along?

Edit:
Another camera related question: Would it be possible to save the camera settings(pan/tilt) in the scenario file?

 

[Urwumpe]

No news on the MLP, I concentrated on finishing the other features currently. Saving the camera parameters is possible and no problem.

When MDUs work again and the payload system is added, we can release a new version and THEN I would say I can resume work on the MLPs.

 

[DaveS]

No news on the MLP, I concentrated on finishing the other features currently. Saving the camera parameters is possible and no problem.

When MDUs work again and the payload system is added, we can release a new version and THEN I would say I can resume work on the MLPs.

A-OK on that! How about adding the ODS? Would love to operate the panels!

 

[Urwumpe]

Work on that. I just make a system to save and restore the state of panel switches to the scenario file automatically.

Design goal is currently: You just add the switch to a panel and give the switch a name, and the panel code write the state to the scenario file and can read it again. Luxury extension is for the switches to save the current position as text label (for example "ON", "GND", "OFF"), so the scenario file will read pretty similar to the switch lists in the Flight Data File.