Space Shuttle Ultra 1.25 Revision B development

[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?

 

[Urwumpe]

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".

Aaaaaaaaaaaaaaaaaaaaaaaaah!

Mathematics!!!!

:focus: