SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

* face missing inboard of salad bowls?

In the highlighted area, should there be a surface, or is it supposed to be open as it is?

* some kinks and holes around the nose cap, at the 5 and 7 o'clock positions when viewed from the front

The nose cap looks beautiful, the area immediately behind not so much. Also, note the gap in the NLGD.

 

[DaveS]

In the highlighted area, should there be a surface, or is it supposed to be open as it is?

It's hard to see in that screenshot as the shading hides a lot of detail. Could you try to apply the textures so I can compare better with the model I'm working with? Or show it in Orbiter?

 

[GLS]

It's hard to see in that screenshot as the shading hides a lot of detail. Could you try to apply the textures so I can compare better with the model I'm working with? Or show it in Orbiter?

It's the area a bit below the center of the image. (That's the LH umbillical, looking forward)

 

[GLS]

Urwumpe, just to make sure we don't collide head on, you aren't doing any work on the include stuff that was talked about a few days ago? I'm adding the trim switches to the panels and I think some improvements could be made in what is in the Atlantis_defs.h and vc_defs.h files.

---------- Post added at 11:01 AM ---------- Previous post was at 10:38 AM ----------

I think I can remove the Atlantis requirement in most, but not all, panels by passing a pointer to the BundleManager in Realize() and the "GetOrbiterCoGOffset() + VC_OFFSET" value in RegisterVC(). The Atlantis.h file is still included in the AtlantisPanel class, which is used by all panels... :uhh:
It's not a huge gain, either in (compile) performance or organization, but I think it is worth an hour or so of my time. :shrug:

 

[GLS]

I've finished an "include cleanup" that removed most of the unneeded dependencies that existed. The file Atlantis.h, although it is still used in several places, now has much less dependencies so "full rebuilds" should now be more rare.
The need for the Atlantis class could probably be reduced by providing classes with a VESSEL object instead, as most only need Orbiter API functions and not Atlantis-specific functions, so for now I won't do the changes in the previous post as something better might be possible.

 

[Urwumpe]

My approach to get rid of some dependencies BTW is using a SubsystemSimulation class as container for the subsystems into libUltra instead of Atlantis now, and derive a "STSSubsystemSimulation" thats used in Atlantis to make handling and configuring the subsystems easier.

For VC Panels, I am thinking about doing the same, but with a VirtualCockpit class as container, that can be specialized for the actual implementation. The subsystem container would then only contain functions to query or change the state of the vessel physics, while the Virtual Cockpit would only contain functions to define animations or cockpit event handlers.

But I am generally working towards getting a bit more loose coupling into it, so its easier to change low-level code without needing to change much in the high-level implementations of the subsystems or application software.

Ideally, it should be possible to program a flight software process without knowing how the subsystem is implemented.

 

[GLS]

Quick question: the elevons in the mesh are positioned at 0º, correct?

 

[Urwumpe]

I would not dare to say different... are they off?

 

[GLS]

I would not dare to say different... are they off?

Their commanding is... wonky: the command signal range is [-1;+1], which maps to [-33;+18]... but for some reason the 0 matches on both ranges, which makes them non-symmetrical. I think the same happens on the DAP, so probably in the end there are no issues... but it doesn't seem right. So now the FCS will calculate an elevon position, convert linearly and uniformly to the [-1;+1] range for transport, and then it gets converted back to angles for animation processing and "position feedback".
The animation enters as the current code is this:

if (aerosurfaces.leftElevon < 0.0) SetAnimation(anim_lelevon, (aerosurfaces.leftElevon + 34.0) / (34.0 * 2));
else SetAnimation(anim_lelevon, (18.0 + aerosurfaces.leftElevon) / (18.0 * 2));

Which is (1) more expensive then needed (yes, one branch is peanuts, but it's still unneeded) and, (2) doesn't animate correctly as the 34.0 should be 33.0... :facepalm: At least it doesn't fed a number outside the bounds of the animation input.

BTW: did I already say that the FCS is a PITA? :uhh:

 

[Urwumpe]

I think the different angles actually come from the mechanism how the elevons are attached to the wing and the hydraulic actuator - they seem to rotate around different axes depending on wether the elevon is moving up or down, despite the hydraulic actuator moving the same distance.

---------- Post added at 01:00 ---------- Previous post was at 00:50 ----------

No, one fixed axis for the elevon. But the hydraulic piston stills seems to be only indirectly attached.

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850008652.pdf

---------- Post added at 01:08 ---------- Previous post was at 01:00 ----------

Here is the reference:

Range and range errors, including how the GPC values are scaled to degrees:

-20° to +20° actually seem to be the real limits relative to the trailing position in SCOM.

 

[GLS]

-20° to +20° actually seem to be the real limits relative to the trailing position in SCOM.

That can't be as move 33+18=51º under command (and the real limits are are futher out), and that's only 40º...

 

[Urwumpe]

Well, see here for the official limits:

Note the software limits: -33 ... +18


Still no idea, why most drawings of the elevons show +/- 20°

 

[GLS]

Not that it this info isn't helpful, but I knew the [-33;+18] range... I'd just like to confirm that the mesh is at 0º (I don't suspect anything wrong, it's just to confirm).

Also, what is the offset between the (Xo, Yo, Zo) and the mesh? I'd like to make a simple spreadsheet so we can easily convert between both.

 

[DaveS]

The mesh has all aerosurfaces (elevons, RSB and body flap) at their neutral positions (0° position). It's the same for anything that moves (SSME TVC, OMS TVC, PLBDs and radiators, K^U band DA) . Only outliers are the RMS and MPMs.

---------- Post added at 10:46 AM ---------- Previous post was at 10:27 AM ----------

And here's what I have measured as far as conversions between the coordinate systems go:

Xo0 = mesh/Orbiter Z24.4118003
Yo0 = mesh/Orbiter X0.00000
Zo0 = mesh/Orbiter Y-10.922

 

[GLS]

Looking at the elevon seal panels, 2 sets of 4-bar linkage equations should be able to properly animate them... the problem is finding the positions of 7 points (6 as we have the elevon hinge). Better leave things as they are for now, as there are more important things to do.

 

[Urwumpe]

Looking at the elevon seal panels, 2 sets of 4-bar linkage equations should be able to properly animate them... the problem is finding the positions of 7 points (6 as we have the elevon hinge). Better leave things as they are for now, as there are more important things to do.

Actually, its much simpler than a 4 bar.



https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850008652.pdf

 

[GLS]

Actually, its much simpler than a 4 bar.



https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850008652.pdf

That's where I was looking (figure 7). I think 2 are needed: the first to calculate the rotation of the bellcrank from the elevon rotation, and the second to calculate the rotation of the panel seal from the rotation of the bellcrank.
Anyway, that's in the future...

 

[Urwumpe]

That's where I was looking (figure 7). I think 2 are needed: the first to calculate the rotation of the bellcrank from the elevon rotation, and the second to calculate the rotation of the panel seal from the rotation of the bellcrank.
Anyway, that's in the future...

Or...simply calculate the point where the elevon seal touches the elevon.

 

[GLS]

And here's what I have measured as far as conversions between the coordinate systems go:

Xo0 = mesh/Orbiter Z24.4118003
Yo0 = mesh/Orbiter X0.00000
Zo0 = mesh/Orbiter Y-10.922

Compared with the animation data on the SSMEs, there seems to be a 0.4852m offset in the Zo-to-Y value, so it should be -10.4368.

---------- Post added 10-26-18 at 06:39 PM ---------- Previous post was 10-25-18 at 11:34 PM ----------

^^ any news on this? I made a spreadsheet to ease the conversion between the 2 systems, but I'd like confirmation of the values before I commit it.

 

[DaveS]

Compared with the animation data on the SSMEs, there seems to be a 0.4852m offset in the Zo-to-Y value, so it should be -10.4368.

---------- Post added 10-26-18 at 06:39 PM ---------- Previous post was 10-25-18 at 11:34 PM ----------

^^ any news on this? I made a spreadsheet to ease the conversion between the 2 systems, but I'd like confirmation of the values before I commit it.

You're correct, I miscalculated the Zo-to-Y value. Our Y0 is located at Zo410 which is location of the PLB sill longerons which converts to -10.414.