SSU Development Thread (2.0 to 3.0)

[DaveS]

Shading doesn't look right. It looks more like a 2D panel, not a 3D one.

Actually the SSPs are flat like that. Here's a photo of the same panel configured for payloads of STS-95, HOST and IEH-03. The purpose of the SSPs are to provide payload customers with a standard panel that can be easily reconfigured to suit any requirements. The payload customer submits a proposed SSP layout to NASA which then reviews it and if it meets all the requirements, then they'll reconfig the SSP to meet that particular customer's layout.

---------- Post added at 08:08 PM ---------- Previous post was at 08:02 PM ----------

Here's the schematic for the SSP when it is not configured for any mission:

---------- Post added at 08:10 PM ---------- Previous post was at 08:08 PM ----------

Here's the final photo I have of an SSP, this time STS-49 the Intelsat VI Reboost mission:

 

[SiameseCat]

I think I will then pick up the work on the Centaur again and use the new talkback code there as well for its panel, so both is based on the same code-base.

On a parallel track, I think I have the research together to create a second prototype for a Java FX 8 based mission editor, after the quick&dirty GUI prototype there. If consensus goes against Java FX (I count the vote as 1/1/1 right now), I would just keep it general and without too many SSU relations.

I'd prefer C# to Java, mainly so we don't have to install the JDK (and so users don't need to install the JRE). I also prefer C# to Java as a language, although I don't have particularly strong feelings there. I haven't done much GUI programming in either C# or Java, so I'm not sure if there's a big difference there.

 

[Urwumpe]

I'd prefer C# to Java, mainly so we don't have to install the JDK (and so users don't need to install the JRE). I also prefer C# to Java as a language, although I don't have particularly strong feelings there. I haven't done much GUI programming in either C# or Java, so I'm not sure if there's a big difference there.

Well, the big issue isn't really the GUI programming. Both use XML files for defining stuff, both follow similar approaches there, both use some sort of view controller pattern to connect GUI and data model, both know data bindings.

The devil is in the detail: C# has no production grade dependency injection framework, the most stable around is NInject. In the Java world, Google Guice has a very strong support now, parallel to Spring (which is much more bloated IMHO than Guice). Should we move towards a modular mission designer, all attempts in the direction of modular systems stopped in C#, while Java is the native language of OSGI bundles and containers like Apache Felix (used in the Glassfish application server) or Eclipse Equinox.

Same with testing frameworks - C# has the minimum necessary, but everything comfortable either costs serious money or is simply missing, while Java means having to choose from a wide range of tools.

Also, the use of partial classes in the standard WPF programming sucks enormously compared to the JavaFX approach of using annotations to bind view controller and XML. The partial classes hide a lot of implementation, which makes debugging pretty time consuming.

You are right about the JDK there, though a Netbeans 8.0.2 installation brings everything you need and allows installing the current reference FXML8 editor as plug-in.

I learned some lot of C#/WPF to the JavaFX8 stuff I learned before, so I am pretty flexible there. Would I have to decide alone, I would take Java for the reasons stated above. It is not so much about the differences in the languages, than about the tools available around both.

 

[GLS]

Remember to also subtract the coordinates of the old state from the texture coordinates so you are not shifting the texture with every update.

Because now every update is done based on the original mesh (instead of the modified by a previous update), there is no need to subtract the old state. Instead we need to subtract the default state, which so far is barberpole = (0,0), so it still worked perfectly without any subtraction. But if the default isn't barberpole then a subtraction is needed, so the subtraction (of the default state) is back in.

EDIT... since new and malloc() are pretty slow, would it be possible to use a static vertex buffer in the DLL or must we create a new array of vertex coordinates in every modification?

Done.

 

[Urwumpe]

@DaveS: Working on the FSS OWP animation, I discovered I could need some measurements of the mesh to fix them. Can you get me the following distances:

FSS_OWP_BRACKET_LENGTH: Length of the OWP bracket from OWP rotation axis to strut axis.
FSS_OWP_STRUT_OFFSET: Offset of the strut rail from the FSS
FSS_OWP_STRUT_LENGTH: Length of the strut that connects OWP and FSS rail.
FSS_OWP_STRUT_NULL_ANGLE: Initial angle of the strut in the mesh, relative to the OWP

Bracket is the part that carries the actual OWP, strut is the part that connects the bracket to the FSS rail.

 

[DaveS]

FSS_OWP_BRACKET_LENGTH: I don't quite understand this one.
FSS_OWP_STRUT_OFFSET: 23.8144 //Is this measured from the center point of the FSS (coordinate 0,0,0)?
FSS_OWP_STRUT_LENGTH: 17.9491//Entire length of the rail
FSS_OWP_STRUT_NULL_ANGLE: 83°s

 

[Urwumpe]

FSS_OWP_BRACKET_LENGTH: I don't quite understand this one.
FSS_OWP_STRUT_OFFSET: 23.8144 //Is this measured from the center point of the FSS (coordinate 0,0,0)?
FSS_OWP_STRUT_LENGTH: 17.9491//Entire length of the rail
FSS_OWP_STRUT_NULL_ANGLE: 83°s

I'll make a drawing on this one, to explain it easier.

---------- Post added at 08:27 PM ---------- Previous post was at 07:46 PM ----------

Here it is:

The bold parts are the required constants

 

[DaveS]

These are what I get when I have measured out things in the mesh:
FSS_OWP_BRACKET_LENGTH: 5.6557
FSS_OWP_STRUT_OFFSET: 17.305
FSS_OWP_STRUT_LENGTH: 17.9491
FSS_OWP_STRUT_NULL_ANGLE: 83°s

 

[Urwumpe]

These are what I get when I have measured out things in the mesh:
FSS_OWP_BRACKET_LENGTH: 5.6557
FSS_OWP_STRUT_OFFSET: 17.305
FSS_OWP_STRUT_LENGTH: 17.9491
FSS_OWP_STRUT_NULL_ANGLE: 83°s

Are you sure about the FSS_OWP_BRACKET_LENGTH? Its only half the length it was before.

const double FSS_OWP_BRACKET_LENGTH = 12.4;
const double FSS_OWP_STRUT_LENGTH = 18.02;
const double FSS_OWP_STRUT_OFFSET = 13.427;
const double FSS_OWP_STRUT_NULL_ANGLE = 88.5; //angle in degrees

 

[DaveS]

You're correct, I read the measurement wrong. The correct number for FSS_OWP_BRACKET_LENGTH is 11.8745.

 

[Urwumpe]

You're correct, I read the measurement wrong. The correct number for FSS_OWP_BRACKET_LENGTH is 11.8745.

That number makes more sense to me. Is the definition of the angle correct or did I analyse this wrong in the code?

EDIT: Is wrong, need to calculate 180 - 83° for the proper angle.

EDIT2: Is more wrong than that... back to the pen & paper.

 

[GLS]

Did you make this? If so, then you just won a place in the "manual writing group" as "head diagram designer". :thumbup:

 

[Urwumpe]

Did you make this? If so, then you just won a place in the "manual writing group" as "head diagram designer". :thumbup:

Yes, a quick job with Inkscape.

But its wrong - I have a systematic linear growth of the distance between OWP strut and its rail while extending - I must have calculated some number wrong.

I know that basic trigonometry is applied in the calculation... and still I must have done something wrong there. :facepalm:

double StrutAngle=acos((FSS_OWP_STRUT_OFFSET-YPos)/FSS_OWP_STRUT_LENGTH)+angle;

EDIT: Found one error... exchanged two values in the definition

EDIT2: Still the distance is growing - the measurements are still off the geometry it seems. So back to the math.

EDIT3: Using the original value for FSS_OWP_STRUT_OFFSET results in closer results, but still the distance to the rail grows... is the rail really parallel to the Z axis?

EDIT4: Calculating with DaveS numbers, I got a Null angle of 72.39°, which is much closer, but there is still a small error between animation and model.

EDIT 5: Using the animation coordinates, I got a bit closer, Null angle now 72.4545°, but still the strut leaves the rail significant at the end of the extension. FSS_OWP_STRUT_OFFSET or FSS_OWP_STRUT_LENGTH must still be wrong.

---------- Post added at 11:08 PM ---------- Previous post was at 09:19 PM ----------

Updated the drawing to the latest findings.

The top image shows the constants used in the animation calculation
the bottom image shows the local variables used for calculating the animation state of the strut.

The X coordinate of the FSS OWP rail would be interesting for me, as well as the accurate length of the strut.

 

[DaveS]

The strut length if you mean the east/west length is 17.9491. The X pos of the rail is 7.1742.

 

[Urwumpe]

The strut length if you mean the east/west length is 17.9491.

Is that the length from animation reference to the point it connects to the rail?

 

[DaveS]

Is that the length from animation reference to the point it connects to the rail?

No, it is of the mesh itself. Could you be more specific of what you mean by "animation reference"?

 

[Urwumpe]

No, it is of the mesh itself. Could you be more specific of what you mean by "animation reference"?

Animation reference is the connection between OWP and strut, where the strut rotates in our animation model.

const VECTOR3 FSS_OWP_STRUT_ROTATION_REF = _V(5.524, 0.0, 22);

 

[DaveS]

Animation reference is the connection between OWP and strut, where the strut rotates in our animation model.

const VECTOR3 FSS_OWP_STRUT_ROTATION_REF = _V(5.524, 0.0, 22);

Then in X axis in it is 1.7.

 

[Urwumpe]

Then in X axis in it is 1.7.

I need the distance in XZ plane between the two points.

 

[DaveS]

I need the distance in XZ plane between the two points.

Could you show on the graphic exactly the points?