Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 10-13-2018, 11:35 PM   #2041
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 * 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?

Quote:
Originally Posted by DaveS View Post
 * 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.
Attached Thumbnails
Click image for larger version

Name:	salad.png
Views:	140
Size:	31.6 KB
ID:	16116   Click image for larger version

Name:	nose.PNG
Views:	134
Size:	29.8 KB
ID:	16117  
GLS is offline   Reply With Quote
Old 10-13-2018, 11:57 PM   #2042
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
  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?
DaveS is online now   Reply With Quote
Old 10-14-2018, 12:22 AM   #2043
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 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)
Attached Thumbnails
Click image for larger version

Name:	saladtex.PNG
Views:	125
Size:	449.0 KB
ID:	16118  
GLS is offline   Reply With Quote
Thanked by:
Old 10-14-2018, 10:01 AM   #2044
GLS
Addon Developer
 
GLS's Avatar
Default

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...
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.
GLS is offline   Reply With Quote
Old 10-19-2018, 10:37 PM   #2045
GLS
Addon Developer
 
GLS's Avatar
Default

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.
GLS is offline   Reply With Quote
Old 10-20-2018, 06:43 AM   #2046
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

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.
Urwumpe is offline   Reply With Quote
Old 10-24-2018, 06:41 PM   #2047
GLS
Addon Developer
 
GLS's Avatar
Default

Quick question: the elevons in the mesh are positioned at 0, correct?
GLS is offline   Reply With Quote
Old 10-24-2018, 07:07 PM   #2048
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

I would not dare to say different... are they off?
Urwumpe is offline   Reply With Quote
Old 10-24-2018, 08:27 PM   #2049
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 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:
Quote:
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... 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?
GLS is offline   Reply With Quote
Old 10-24-2018, 11:08 PM   #2050
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

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/c...9850008652.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.

Last edited by Urwumpe; 10-24-2018 at 11:12 PM.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 10-24-2018, 11:22 PM   #2051
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 -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...
GLS is offline   Reply With Quote
Old 10-24-2018, 11:43 PM   #2052
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Well, see here for the official limits:






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


Still no idea, why most drawings of the elevons show +/- 20
Urwumpe is offline   Reply With Quote
Old 10-25-2018, 08:17 AM   #2053
GLS
Addon Developer
 
GLS's Avatar
Default

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.
GLS is offline   Reply With Quote
Old 10-25-2018, 08:46 AM   #2054
DaveS
Addon Developer
 
DaveS's Avatar


Default

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, KU 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:

Code:
Xo0 = mesh/Orbiter Z24.4118003
Yo0 = mesh/Orbiter X0.00000
Zo0 = mesh/Orbiter Y-10.922
DaveS is online now   Reply With Quote
Thanked by:
Old 10-25-2018, 06:25 PM   #2055
GLS
Addon Developer
 
GLS's Avatar
Default

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.
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 11:48 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.