Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

I started working on the VAB.dll today. Will also pay attention that we can change visual depending on current era.

Some big picture development questions:

How does the dev team think about kicking the staging code out of SSU, replace it by using attachments?

Next: What about at this point remove the subsystem code from the "Atlantis" project and compile this code subsystem-wise into static libraries (.lib) for having a better project structure? Like using "ultra_gnc.lib" for the GNC components. By this, we could also make the main vessel class more compact by moving more stuff away from it and reduce the dependencies on it.

I think about having the subsystems more and more separated from the "Atlantis" code, until we can use them reliable for other vehicles. I have some early notes done for the changes towards it, but these need some more thinking now that I have more time for it. Such a "Ultra.lib" project would then also allow including such features like radio communication, TACAN and MLS by a single central DLL(maybe as Orbiter-plugin for allowing enabling/disabling of such advanced features).

I'll make a special post about the large scale plan as soon as I have confidence in it and finished some drawings, but these two things above are what I am already sure to make sense.

Points that are still not comfortable for me are:
- Additional levels of hierarchy for subsystems, like grouping them by Module/Assembly, so complete groups of subsystems can be removed/added at once.
- Changes to the scenario file format for having a standard parser for the subsystem/VC data, that does not rely on a fixed vessel structure.
- How to connect vessel visual to subsystems, like adding/removing ODS or Spacelab.

Using attachments for the ET and SRBs is probably a good idea, although we'll need some way of controlling SRB gimballing, etc. The other issue will be transferring mass and thrust over to the shuttle vessel, but that'll be easy.

The main problem I have with using static libraries are that it'll be difficult to split the subsystems up into distinct libraries. For example, a lot of libraries will need to communicate with the power systems library. Also, a lot of this stuff will be fairly shuttle-specific, so it wouldn't be useful for other vessels.

---------- Post added at 02:02 PM ---------- Previous post was at 01:57 PM ----------

The RMS/MPM systems create the additional visuals in the Realize function; this should work for other subsystems.

 

[Urwumpe]

Using attachments for the ET and SRBs is probably a good idea, although we'll need some way of controlling SRB gimballing, etc. The other issue will be transferring mass and thrust over to the shuttle vessel, but that'll be easy.

All can be solved, SRB gimballing for example over a standard serial bus interface.

The main problem I have with using static libraries are that it'll be difficult to split the subsystems up into distinct libraries. For example, a lot of libraries will need to communicate with the power systems library. Also, a lot of this stuff will be fairly shuttle-specific, so it wouldn't be useful for other vessels.

Yes, the libraries would depend a lot on each other, but would be just split for reducing build times - currently, any changes to the Atlantis.h results in effectively a complete rebuild. And when something is changing in the subsystems, this also affects a more source files than needed.

I don't think the subsystems are all very Shuttle specific, and even if they are, they are often having enough similarities to other subsystems of that kind that refactoring them into more general classes is no large effort. I did a rough comparison between Space Shuttle and Gemini, the general kinds of subsystems are almost the same, only number and specific model varies. Building a Gemini simulation from SSU code would be not that much work anymore.

The RMS/MPM systems create the additional visuals in the Realize function; this should work for other subsystems.

Yes, but some more stability for handling the meshes would be good. Currently, it works best when there are slots for the additional meshes reserved, which means you need dummy meshes if something is missing for filling the gap.

 

[SiameseCat]

My main worry with the libraries is that the dependencies between libraries will make compiling more difficult. As far as reusing them in other vessels, I suspect there'll probably be too much shuttle-specific stuff to use the libraries as-is for other projects; some modifications will be needed. We could use base classes to do most of the work, and then have derived classes that will be used for SSU.

 

[Urwumpe]

My main worry with the libraries is that the dependencies between libraries will make compiling more difficult.

Maybe a single large library then? I am just against writing for example low-level communication stuff for the MLP or VAB, only to write it again for the Orbiter.

As far as reusing them in other vessels, I suspect there'll probably be too much shuttle-specific stuff to use the libraries as-is for other projects; some modifications will be needed. We could use base classes to do most of the work, and then have derived classes that will be used for SSU.

Yes, but that is still a good start - of course it would be impossible to use all stuff just the same. But if we could remove the 20% Shuttle specific code from a class of subsystems, it would already be nice.

 

[DaveS]

Just want check something: Is anyone else besides me getting a CTD with the Spacecraft3.dll based VAB that checked in whenever the Crawler is the scenario? This is when trying to change focus from the CT to the VAB.

Since we're not going to use Spacecraft3.dll for the VAB, this is just a check.

---------- Post added at 06:14 PM ---------- Previous post was at 01:00 AM ----------

Almost done with the orbiter sling set. Just need to finish the forward sling and then do the aft sling.

 

[Urwumpe]

Almost done with the orbiter sling set. Just need to finish the forward sling and then do the aft sling.

Doing some tool work before getting back to the VAB, think I'll get to the door animation today.

EDIT: Current minor upgrade: Working on getting the MDMs implemented. Will add a tiny tool project to the repository, which allows creating MDM PROM images (1 KB).

 

[DaveS]

Doing some tool work before getting back to the VAB, think I'll get to the door animation today.

Good. If you want, you could use the crane sound file for the doors, as they make a similar electrical "buzz" noise when they're being moved.

 

[Urwumpe]

Good. If you want, you could use the crane sound file for the doors, as they make a similar electrical "buzz" noise when they're being moved.

I thought so. Will need to learn a bit more about Orbitersound for the internal sound, never used it so much.

The MDM simulation will definitely permit creating a complete MDM from the PROM image, since the first 16 words encode the installed modules in the MDM. Should make development easier since many MDMs are interchangeable.

 

[DaveS]

Checked a new VAB exterior mesh which has new ET vertical cell platforms now at the correct levels. Also prepared the Low Bay to receive its internal structure later on.

 

[DaveS]

Almost done with the Low Bay structural interior:

 

[Urwumpe]

Does somebody know what "CAPRI" means in the context of the IMU? I can't find anything about it, but it was important enough to assign two discrete lines to it.

Also, can somebody help me with something elemental: Where is the origin of the Body coordinate system relative to the CoG of the vehicle in Orbiter? The positions of the various sensors is given relative to this, but a Z coordinate of 406.4 inches suggests the center of the body coordinate system is somewhere below the Orbiter, not at the center of gravity.

 

[retro]

[FONT=Arial,helvetica][SIZE=-1]

Does somebody know what "CAPRI" means in the context of the IMU? I can't find anything about it, but it was important enough to assign two discrete lines to it.[/SIZE][/FONT]

[FONT=Arial,helvetica][SIZE=-1]CAPRI[/SIZE][/FONT] [FONT=Arial,helvetica][SIZE=-1]capacitance rate integrator[/SIZE][/FONT]

Unit Based on MEMS Capacitive Accelerometer and Rate Sensor

device that employ differential capacitance to sense acceleration and Rate changes.

 

[Urwumpe]

Thank you retro!

so it is related to the velocity measurements of the IMU.

 

[retro]

Yes it is!

 

[Donamy]

Also, can somebody help me with something elemental: Where is the origin of the Body coordinate system relative to the CoG of the vehicle in Orbiter? The positions of the various sensors is given relative to this, but a Z coordinate of 406.4 inches suggests the center of the body coordinate system is somewhere below the Orbiter, not at the center of gravity.

Could it be the COG of the stack ?

 

[Urwumpe]

Could it be the COG of the stack ?

I am not sure, that is why I ask. If somebody could find it out, I could place the AAs, RGAs and IMUs at the original locations and produce exact outputs, if not, they would have higher errors, but still work.

 

[SiameseCat]

Have you looked at page 1.1-7 (page 37 in the PDF) of the SCOM? This talks about the coordinate system, although it doesn't seem to mention the CoG.

 

[Urwumpe]

Have you looked at page 1.1-7 (page 37 in the PDF) of the SCOM? This talks about the coordinate system, although it doesn't seem to mention the CoG.

Yes, I have. Doesn't help much getting it aligned with the Orbiter stuff for me. I also have the Orbiter drawings from NASA.

 

[tblaxland]

I also have the Orbiter drawings from NASA.

Can't you measure the offset from the mesh then? All you need is the x & z coordinates* of one well known point (or two well known planes) from the drawings and the corresponding y & z coordinates from the mesh to get the offset vector.

* The orbiter coordinate system y=0 plane and mesh x=0 plane should be coincident.

 

[DaveS]

Yes, I have. Doesn't help much getting it aligned with the Orbiter stuff for me. I also have the Orbiter drawings from NASA.

Well, I do know that the null X axis is located 236" forward of nose tip of the orbiter. The Xo/Yo planes meet each other at Zo 400".

Does this help?