Space Shuttle Ultra 1.25 Revision B development

[ky]

Added railings:

 

[DaveS]

The new orbiter is rapidly approaching completion. AS of right now this is the break down:

FWD work: 100% complete and closed out
Midbody and PLB: 90% complete, missing stands for aft cameras and the aft PLBD bulkhead latches
Aft compartment: 80% complete, missing the ET umbilical wells and doors
Wings: 100% complete and closed out
Landing gear: 100% complete and closed out
Vertical stabilizer: 100% complete and closed out
OMS pods: Uncertain, still needs to be reworked to fit the new aft compartment shoulders

I think that pretty much covers it.

---------- Post added at 08:17 PM ---------- Previous post was at 05:11 PM ----------

Latest screenshots of the new Orbiter:

 

[Urwumpe]

Looks almost too perfect now... shouldn't there be flood lights and so on on the floor?

And how many triangles would it add to make the T-0 panels a mesh with a more specular material?

 

[DaveS]

Looks almost too perfect now... shouldn't there be flood lights and so on on the floor?

The flood lights are there, see the first image. Anything else is mission-specific(keel latches, bridge fittings etc.).

And how many triangles would it add to make the T-0 panels a mesh with a more specular material?

Not sure. The T0 panels are actually covered by the same FRSI blankets as the rest of the aft compartment. Only on vehicles 102 and 099 were they not covered and just exposed aluminum skin. FRSI has a smooth appearance while AFRSI has a quilted rough appearance.

 

[Urwumpe]

Well, still, it has largely different material properties compared to the rest of the aft section:

That is what I noticed, that the T-0 plates look really like painted on the ship. What they are of course. But they should not be. And especially the propellant fill/drain line is pretty prominent, it might justify a few polygons.

 

[DaveS]

Well, still, it has largely different material properties compared to the rest of the aft section:


That is what I noticed, that the T-0 plates look really like painted on the ship. What they are of course. But they should not be. And especially the propellant fill/drain line is pretty prominent, it might justify a few polygons.

That's just a difference in wear during entry. You can see the same pattern on the midbody, vertical tail and aft RCS pod. The blankets just like the tiles are replaced every so often during the OPF flow.

 

[DaveS]

Today has been mostly spent researching and making the new ET umbilical wells and doors on the orbiter. I have just finished up the new doors and will be outfitting the the actual umbilical wells tomorrow.

---------- Post added 08-17-13 at 10:54 PM ---------- Previous post was 08-16-13 at 11:25 PM ----------

I need some help finding either photos or technical documents that illustrate the ET umbilical disconnect plates on the orbiter in the extended configuration. I have had no luck finding any on my own so maybe any of you have come across anything on this subject.

 

[N_Molson]

Really impressive 3D modelling & texturing, nice work ! :thumbup:

 

[GLS]

Hi! Some news on the MPS front:
> added He System
> added more "features" to the SSME and it's controller (using the limits switch, some redlines and stuff)
> improved the visuals of the OMS/MPS display in the CRTMFD

On the much anticipated release I have to say: please don't wait for me. Because it's still going to be at least another month until I get this to a configuration good enough to commit, then you add testing and bug fixing and before you know it's Christmas...

I also have to make a request to anybody that knows panels: need the SSME S/D PBs on C3 and PRPLT Dump, He Interconnects and Pneumatics switches on R2, so I can now try to make more things. :thumbup:

Another thing, should I also "wash the face" of the APU display in the CRTMFD, or is the whole CRTMFD going to be replaced with something new? (noticed alot of code for other displays commented out, ASC TRAJ, etc...) If anybody wants I can post a pic of the OMS/MPS display for you to see.

 

[Urwumpe]

GLS, one thing there: I current work on the ATVC and have some improvements for the hydraulics model there. Now, which outputs would you need from the hydraulic valves in the MPS for your engine/MPS model to do its job?

We could then unify the hydraulics over the next weeks and use standard components from the "hydraulics" namespace there.

The ATVC will have only small impact on the SSME implementation, you only need a function to get/set subsystem reference frame (position and orientation) and apply the new reference frame then on the Orbiter thrusters. I will implement this once I am happy with the hydraulic actuator simulation.

The actual gimballing will be handled by a "GimbalMount" class, that has a SSME and two hydraulic actuators as children.

The already started ATVC class currently gets refactored, instead of one big blob, it will now be made of similar modules for SSME1, SSME2, SSME3, SRB1 and SRB2.

The CRTMFD only handles those formats itself, that are produced by the MEDS display. What goes over the IDP is instead produced by the IDP class (and should actually be defined by a DEU program made of 16 bit words, that is updated twice per second by the GPC). Thats all displays that are driven by the GPCs and have a Function+OPS/SPEC/DISPLAY number.

 

[GLS]

For the SSME hyd valves I think the only need hyd press (and maybe hyd return)... I'm still thinking about the whole valve scene (pressure actuated, solenoid, hyd...) and how they connect to the supply of whatever moves them.

On the ATVC I think there is no need to change/move the SSME class, because it doesn't care where the engine is pointing (the thrust vector is defined somewhere in the Atlantis class where it interfaces with the orbiter API), it just controls the thrust level (thru some other function in the Atlantis class). The ATVC class should exist, and should take commands from the GPCs and convert them into inputs into all TVC hyd actuators. Those actuators, inside a GimbalMount class, should do their thing and the GimbalMount should then change the vectors in the Atlantis class accordingly. Just my 2 cents.

On the CRTMFD... I'm not following you... is the whole thing getting dumped, just part (which?) or it all stays?

 

[Urwumpe]

On the ATVC I think there is no need to change/move the SSME class, because it doesn't care where the engine is pointing (the thrust vector is defined somewhere in the Atlantis class where it interfaces with the orbiter API), it just controls the thrust level (thru some other function in the Atlantis class). The ATVC class should exist, and should take commands from the GPCs and convert them into inputs into all TVC hyd actuators. Those actuators, inside a GimbalMount class, should do their thing and the GimbalMount should then change the vectors in the Atlantis class accordingly. Just my 2 cents.

Well, we need to change both, since the gimbal axis is not the same as the thrust force reference. Also, while the Atlantis class (or another central class) should be responsible for allocating the thruster handles (so loading/saving works fine), during simulation time, the SSME class should be fully responsible of it and its parameters, including position and direction. It is just simpler when only one class is responsible for the subsystem, and other classes are only involved, where it brings us a gain.

On the CRTMFD... I'm not following you... is the whole thing getting dumped, just part (which?) or it all stays?

The thing will stay (though I don't like it, but it is really more economic for now), but we moved the drawing code for all the displays that the GPCs show into the IDP (Integrated Display Processor) class.

In the real shuttle, the GPCs would load a display format table (DFT) from magnetic tape, process it in memory by replacing special drawing operation codes called format words with patterns of native IDP format words (Like: Replace this 16 bit word by a formatted output of the variable at GPC memory location X), and then sends the whole processed display format buffer to the IDP. Now that the IDP knows how to draw the display. Until another display should be displayed, the GPC now only updates the dynamic part of the DFT, located at the end of the DFT. Twice per second, it again processes the format words, replaces special words by patterns of native FWs and then sends the display format buffer to the IDP.

In the old DEU, the format words directly controlled the electron beam of the CRT. The CRT was a storing display tube, like you used for radars or oscilloscopes. It not simply moved the beam in a fixed pattern and alternated the intensity, it made the beam draw lines or circles, and by a special character matrix in the path of the electron beam, also text and symbols. It was also able to blank parts of the screen on command. Each format word could mean something like "Move beam to x,y", "Select an Space shuttle symbol", "Activate beam at medium intensity", etc.

In the IDP, the old DEU SP-0 processor was only emulated. The 386SX processor in it simply took the format words and converted them into drawing instructions for the connected MDU, which it then gave the MDU displays via MIL-STD-1553 data bus.

I hope, this text was a better reading for you all. :lol:

Sadly, I still have no full knowledge of the display format codes. I know that the original DEU had 18 instructions, and that the IDP added 2 new instructions for supporting the PFD display modes. Also it is likely that the IDP generated most displays actually and the MDU really only painted them and returned soft-button pressed events to the IDP.

 

[GLS]

Well, we need to change both, since the gimbal axis is not the same as the thrust force reference. Also, while the Atlantis class (or another central class) should be responsible for allocating the thruster handles (so loading/saving works fine), during simulation time, the SSME class should be fully responsible of it and its parameters, including position and direction. It is just simpler when only one class is responsible for the subsystem, and other classes are only involved, where it brings us a gain.

I disagree with the undelined, but as long as it works it's fine.

So I'll continue the "upgrade" of the CRTMFD. Probably could commit the changes in a few days... would have to remove the calls to the functions that are still in work... I'll give news

 

[Urwumpe]

I disagree with the undelined, but as long as it works it's fine.

Well, which class would you think is better suited for that?

So I'll continue the "upgrade" of the CRTMFD. Probably could commit the changes in a few days... would have to remove the calls to the functions that are still in work... I'll give news

Well, we can move it somewhere else afterwards anyway.

 

[DaveS]

I also have to make a request to anybody that knows panels: need the SSME S/D PBs on C3 and PRPLT Dump, He Interconnects and Pneumatics switches on R2, so I can now try to make more things. :thumbup:

Press Ctrl-3 to bring up the Coordinate Display Mode debug string. I believe it shows the necessary data you need to get the switches you need working.

 

[ky]

Concerning the ATC tower, I won't have much time to work on it now that school has restarted, so I'll pass along the mesh for someone else to complete if it is needed ASAP.

 

[GLS]

Just commited the "new" CRTMFD (hope it looks good). I was wondering if it was possible to "pre-draw" all the fixed stuff into a separate hdc. When time came to draw the display it copied the "pre-draw" before putting the numbers and "movable parts". I think it would improve speed a little, but since it's not slow now and it's all going to the IDP, I think it's better to leave it as is.

Well, which class would you think is better suited for that?

Like I said before:

The ATVC class should exist, and should take commands from the GPCs and convert them into inputs into all TVC hyd actuators. Those actuators, inside a GimbalMount class, should do their thing and the GimbalMount should then change the vectors in the Atlantis class accordingly.

I think the direction of thrust and the magnitude of thrust are 2 separate things. The engine doesn't care where it's pointing, and the actuators don't care it the engine is on or off.

Press Ctrl-3 to bring up the Coordinate Display Mode debug string. I believe it shows the necessary data you need to get the switches you need working.

Oh, I thought I needed one of those nifty 3D editors to do it. I'll give it a try then, many thanks!

 

[Urwumpe]

I think the direction of thrust and the magnitude of thrust are 2 separate things. The engine doesn't care where it's pointing, and the actuators don't care it the engine is on or off.

That doesn't solve the problem that one class should be responsible for handling the direction.

I could also make the GimbalMount handle this, but then it would be specialized for the SSME and can't do anything else. If I want to make it general purpose (so it also works for OME and SRB), I need a class to handle the translation from gimbal to Orbiter thruster. I could write a simple general proxy there, but then, it would also not hurt letting the SSME class handle this by implementing the proper methods of the Subsystem superclass and avoid introducting a new class there.

Also, the gimbal mount would better care about the engine on/off case... The difference between engine dry mass and engine wet mass are a few hundred kg (about 15% of the dry mass), enough to have an effect on the indications in the flight deck.

If we want to be accurate, we would also need to include the ignition transients of the SSME - they have a lower frequency than the vibrations at main stage and can transfer into the hydraulic system.

 

[GLS]

That doesn't solve the problem that one class should be responsible for handling the direction.

I could also make the GimbalMount handle this, but then it would be specialized for the SSME and can't do anything else. If I want to make it general purpose (so it also works for OME and SRB), I need a class to handle the translation from gimbal to Orbiter thruster. I could write a simple general proxy there, but then, it would also not hurt letting the SSME class handle this by implementing the proper methods of the Subsystem superclass and avoid introducting a new class there.

Also, the gimbal mount would better care about the engine on/off case... The difference between engine dry mass and engine wet mass are a few hundred kg (about 15% of the dry mass), enough to have an effect on the indications in the flight deck.

If we want to be accurate, we would also need to include the ignition transients of the SSME - they have a lower frequency than the vibrations at main stage and can transfer into the hydraulic system.

GimbalMount would be general purpose. Just give it another actuator type and another thrust vector to play with. It doesn't know which engine that thrust vector represents, and it doesn't care. It will just manipulate that vector according to the actuator inputs.
About the SSME ignition transients I think it's a loooong way down the road, right next to the body flap vibrating during ascent, or the OME nozzles buckling on SSME ignition....
But like I said before: as long as it works -> go for it.

Back to the panels and switches, I managed to get everything to work except the SetReference call because I don't know how to get those coordinates...:shrug:

 

[Urwumpe]

Back to the panels and switches, I managed to get everything to work except the SetReference call because I don't know how to get those coordinates...:shrug:

OK, THERE you need the coordinates... I often used MeshWizard until it failed.

EDIT: Maybe we should encourage "Mesh documentation" by the graphical wizards, so we instruction pushers have a document with the official reference coordinates for every mesh and desired animation.