Space Shuttle Ultra development thread

[Urwumpe]

Payload interfaces analysis

Lets assume, we use a system based on a fixed number of attachments, which can partially get moved. Lets assume also, that the payload attachments will be at the end of the parent->child attachment list. The order of the attachments shall stay constant over a long time.

So, which P->C attachments do we need? my proposal:

Fixed:
0. RMS End-effector
1. OBSS
2. MMU1 (historic, do we need them?)
3. MMU2
4. Docking port Aux (allow us simulating soft docking)

dynamic centerline payloads, controlled by the payload 1-3 interfaces

5. Payload 1
6. Payload 2
7. Payload 3.

Static centerline Payloads:

8. Static C/L payload 1
9. Static C/L payload 2
10. Static C/L payload 3.

Pseudo static Port sill payloads (Are static inside the Shuttle, but can later get separated by EVA)

11. Port static 1
12. Port Static 2
13. Port Static 3

The same starboard

14. Starboard Static 1
15. Starboard Static 2
16. Starboard Static 3

Anything missing?

 

[Kyle]

btw question, When you launch Ultra, how do you get auto pilot to work? I have clicked all the APU stuff, what configuration do they need to be in?

 

[DaveS]

btw question, When you launch Ultra, how do you get auto pilot to work? I have clicked all the APU stuff, what configuration do they need to be in?

Make sure that the pressure in all three HYD systems is 3000 PSI before you launch.

Sounds like you have only partially started the APUs, which only brings up the HYD systems pressure up to 900 PSI.

We should really implement a C&W Master Alarm sound for this. It would tie nicely into Urwumpe's GLS idea since it would cause a hold at T-4 minutes and refuse to launch unless you had cleared the problem.

 

[DaveS]

Donamy: Any news from C3PO on the ODS ring animation?
SiameseCat: Any news on the RMS? Any new features in work? Maybe it is time to make the RMS panels working and getting rid of the debug string text?

 

[DaveS]

Just checked in a few small modifications to the aft pilot and RMS stations, while also checking in a bug fix for the ET which caused it to lose it's textures at ET sep.

 

[SiameseCat]

SiameseCat: Any news on the RMS? Any new features in work? Maybe it is time to make the RMS panels working and getting rid of the debug string text?

I've actually been working on the attitude autopilot lately, not the RMS. I'm planning to start work on the RMS again soon.

 

[Donamy]

The animation now works for the ODS, however, I am adding a AirlockVC to it.

 

[DaveS]

The animation now works for the ODS, however, I am adding a AirlockVC to it.

Nice. Can't wait to see it in action controlled by the APDS panels.

 

[DaveS]

Assembly -> Prelaunch -> Launch -> Orbit...

How serious is this? I just happen to have a partially complete VAB with interior on my HDD. Screenshots below.

 

[Donamy]

Very cool !!

 

[DaveS]

Very cool !!

Thanks. If we're going to have rollout ops we're going to need a Crawler. But the question is: in which config? The Crawler has changed it's appearance throughout the years.

Shoould we go with it's post RTF appearance or some other config?

Here's a good page which documents the major changes throughout the years: http://www.axmpaperspacescalemodels.com/CrawlerTransporter.html

 

[Donamy]

No one could tell the difference.

 

[DaveS]

No one could tell the difference.

Well, you could. Prior to STS-114 the crawlers didn't have those 4 large exhaust pipes in front of them and the cooling radiators were monuted slightly offset from the main body of the crawlers.

But maybe you're right, nobody who hasn't done the research would notice the differences. So I suggest we go with post-114 version, with the exhaust pipes.

 

[DaveS]

Some new MLP screenshots from GMAX. Now added the SRB overpressure water bags and the "rain gutters" to Sides 2 and 4 of the MLP. Now working on the OTV cameras.

 

[DaveS]

An update on the MLP: I have been researching the MLP and I have found that the Side 1 decks and stairs have been improperly aligned with respect to the Space Shuttle Vehicle(SSV).

This is now being corrected to match the research I done.

 

[GLS]

Assembly -> Prelaunch -> Launch -> Orbit...

Thank god (MartinS) for time warp! Otherwise we'd have to wait 4 months just to launch!:lol:

I have some questions regarding the MPS sim:
1) should I make preparations to have the sim start in flight (like quicksave during ascent), or will it start always in the pad in a pre-ignition state?
2) the real EIUs get commands from all 4 GPCs. Is this going to happen here or can I expect only one command?
3) must I create the engines???
4) in addition to the SSME, EIU and ATVC(not sure I know enough right now to do it...), should a MPS class exist for PMS and He sys???

The work is going to suffer about a week delay due to the fact that a DVD of mine with some SSME docs is some 370Kms away from me...:compbash: but it's being mailed to me as we speak...

 

[Woo482]

I know this is Kind off of topic But what will the crawler be? a .cfg or space craft 3?

 

[DaveS]

I know this is Kind off of topic But what will the crawler be? a .cfg or space craft 3?

Neither. It will be custom DLL as needs to a be special vehicle.

 

[Urwumpe]

Thank god (MartinS) for time warp! Otherwise we'd have to wait 4 months just to launch!:lol:

I have some questions regarding the MPS sim:
1) should I make preparations to have the sim start in flight (like quicksave during ascent), or will it start always in the pad in a pre-ignition state?
2) the real EIUs get commands from all 4 GPCs. Is this going to happen here or can I expect only one command?
3) must I create the engines???
4) in addition to the SSME, EIU and ATVC(not sure I know enough right now to do it...), should a MPS class exist for PMS and He sys???

The work is going to suffer about a week delay due to the fact that a DVD of mine with some SSME docs is some 370Kms away from me...:compbash: but it's being mailed to me as we speak...

Welcome in my club... all spaceflight reading I have with me in holidays is a soyuz book. :dry:

1) Ideally, you have to assume that the scenario can get saved and restored any time. Of course, we are not always following this ideal perfectly. But over time, it should be possible. If you can't allow saving during the ignition sequence, we can accept it, but after MECO, saving must work again.

2) Make it one commanding GPC for the start. We can later adapt it to use the Shuttle Bus interface and support different command paths. In reality, 4 GPCs will command three EIUs. (Each GPC has a different string) But I have not yet finished the Shuttle Bus interface, and I don't want you having to work with daily changing interfaces. If you want to speed this up, consider the following: The Shuttle Bus interface does a rather abstract system. It transfers data from one memory buffer to another. What is important is: How much data do you have and how often does it need to be transfered to which target? And which commands and data do you accept? The Shuttle Bus interface will most likely use 32 bit floating point numbers (IEEE floats instead of realistic IBM floats, but pssssst... ) and 16 integer numbers (short and unsigned short)

3) If it works, yes. But we will need a way to group all SSMEs to one thruster group for manual control.

4) I would say, it makes sense, but for example, the Helium system is so closely tied to the SSME, that you can also make it part of the SSME. The propellant management system can also be done in multiple classes, but I have not thought about it much. It would be cute if you can manage the amount of propellant trapped inside the propellant lines after MECO and during the purge sequence - we might need it for realistic dynamics.

 

[Pilot7893]

My autopilot not only not work, but give me no control whatsoever :'(