Project Firebird II HLV + RARoG shuttle

[K_Jameson]

These wings so curved suggest an idea: to fold it around the body of the spaceplane during the ascent, and to deploy it only for the reentry and the landing.

Seriously, I think that a curvature so marked will affect the lift generated by the wing. I guess that a significative portion of the wing should have a much more modest dihedral, if not 0°, instead of this enormous positive dihedral.

No offense intended! It's a really cool spacecraft.

EDIT
Also, I think that such a dihedral could work better in negative, rather than positive, allowing to exploit the "compression lift" effect, as in the North American XB-70 Valkyrie. This could lead to a substantial improvement in the lift/drag ratio at high velocities, allowing a larger cross-range.

 

[Cizurator]

Folding the wings around the hull is surely an interesting idea, but i can't see any significant pros in this case. The folding mechanism would take a lot of internal space, and it would be a weak point of the wing during reentry. (But thanks for your idea! )

When you look at my wing, you'll quickly find out that i have almost no knowledge of how a hypersonic wing should look like. It's design is more about aesthetics than anything else.

 

[Cizurator]

A delicate problem has halted my work.

I'm trying to set up a grapple/attachment point for robotic arm using spacecraft3 manual. The attachment point itself is no problem, but the grapple is. It says following about setting up the grapple:

For the grapple of the robotic arm,you must define an animation component without
reference to mesh groups. The transformation will be applied to a triangle. You must defined the 3 points coordinates by using:
• TIP_1=(-2.26,1.71,-6.5) : first point coordinates
• TIP_2=(-2.26,1.71,-7.5) : second point coordinates
• TIP_3=(-2.26,2.71,-6.5) : third point coordinates
These coordinates will be used to move dynamically the attachment position associated with the grapple in accordance with the robotic arm motion. Except for the GROUPS parameter that is replaced byTIP_1, TIP_2 and TIP_3, all other parameters of the animation component must be specified.

Sooo... it actually doesn't say a word about how these TIPs are specified.

At first I assumed, that it means to specify a triangle of the mesh. However, when i looked at those coordinates, as well as other examples (i studied a grapple specification in one of Greg Burch' files), i quickly figured out, that it is rather specified by the attachment axis: TIP_1 and TIP_2 are directly on the attachment axis, and TIP_3 is above the TIP1 (Y+).

So i tried to imitate these findings in my case. However, in burch' case the attachment point axis goes simply along the Z axis (0,0,1), but mine is a little bit rotated by X and Y, so i adjusted the triangle to correspond with it:

(note: the depiction of TIP_3 is not precise in this quick sketch. It's a bit further towards Z-, so the inner angle at TIP_1 is still approx. 90°

The grey cylinder represents my robotic arm. The blue grid represents XYZ axis. The green line represents the axis of the attachment point, and green angles show it's orientation to the XYZ grid. The red triangle stands for my three TIPs.

I figured out and inserted necessary cooridinates for all three tips, but when i loaded the scenario and grappled the HST (for example), the HST stared shaking and rotating - something was wrong. I have tried to find a solution for many hours...

So my desperate and beseeching question is: how to define TIP_1, TIP_2 and TIP_3?

 

[Notebook]

What values are you using for the TIP_1, and the others?


EDIT:
If it help...! This is the ini file for an crane I did on one of my add-ons:

[CONFIG]
MESHNAME="spacecraft\Gantry_Crane"
SIZE=9.
EMPTY_MASS=1000
FUEL_MASS=1000
MAIN_THRUST=5000
RETRO_THRUST=5000
COG=10.18

[PARENT_ATTACH_0]
NAME="rms"
POS=(0,0,0) ;POS=(0,-4,0)
DIR=(0,1,0)
ROT=(1, 0, 0)
RANGE=4
LOOSE=0

[ROBOTIC_ARM]
JOINT_0_NAME="Hoist"
JOINT_0_SEQ=0
JOINT_0_RANGE=(0,1)
GRAP_SEQ=0
GRAP_ATTACH=0


; Hoist cable scale
[ANIM_SEQ_0]
INIT_POS=0
DURATION=4

;Gantry_Crane: This is the grapple point motion
[ANIM_COMP_0]
SEQ=0
RANGE=(0,1)
TIP_1=(0,6,0.1)
TIP_2=(0,6,-0.1)
TIP_3=(0,6.2,0.1)
TYPE=TRANSLATE
SHIFT=(0,-4,0)

;Hoist cable translate, -y only
[ANIM_COMP_1]
SEQ=0
GROUPS=20,21,22,23,24,25
RANGE=(0,1)
TYPE=TRANSLATE
SHIFT=(0,-4,0)

;Constant Tension, -y only
[ANIM_COMP_2]
SEQ=0
GROUPS=19
RANGE=(0,1)
TYPE=SCALE
SCALE=(1,2.8,1)
REF=(0,17.6,0)
SHIFT=(0,-4,0)

I went through Gregg Burch's stuff too!

N.


N.

 

[Cizurator]

Attachment point:

[PARENT_ATTACH_0]
NAME="arm_grapple"
POS=(-1.794,0.139,-5.055)
DIR=(-0.1218,-0.04361,-0.9925)
ROT=(0,1,0)
LOOSE=0
RANGE=0.5

Wrist roll animation:

; wrist roll
[ANIM_COMP_111]
SEQ=15
RANGE=(0,1)
TIP_1=(-1.794,0.139,-5.055)
TIP_2=(-1.542,0.122,-5.388)
TIP_3=(-1.794,0.363,-5.063)
TYPE=ROTATE
ROT_AXIS=(-0.1218,-0.04361,-0.9925)
ROT_PNT=(-1.794,0.139,-5.055)
ANGLE=900
PARENT=110

This is another depiction of the situation according to my current understanding. The grapple should be facing rearwards, and rotated 7° to the left and 2,5° down

 

[Notebook]

I don't see a [ROBOTIC_ARM] definition, or have you not posted all the .ini?

Can't see anything wrong with the syntax
N.

 

[Cizurator]

I don't see a [ROBOTIC_ARM] definition, or have you not posted all the .ini?

Can't see anything wrong with the syntax
N.

These are just selected parts, of course.
The entire .ini is very, very long.

 

[Notebook]

Thought it might be!
Must admit there was a lot of trial and error with the TIP_ values. Don't think I understood it, and definitely forgot now. I'll have a play around and see if anything comes back.

N.

 

[Cizurator]

Thought it might be!
Must admit there was a lot of trial and error with the TIP_ values. Don't think I understood it, and definitely forgot now. I'll have a play around and see if anything comes back.

N.

That's exactly what I'm doing now. I managed to rotate it 7° by Y simply by shifting TIP_2 to the left, but when i try to make the second rotation by X, it starts doing crazy rotations. Maybe that's because the inner angle at TIP_1 is no longer exactly 90°... just my assumption.

There's still some important rule I'm missing. :idk:

 

[DaveS]

TIP_1: POS
TIP_2: POS+/-DIR
TIP_3: POS+/-ROT

 

[Cizurator]

TIP_1: POS
TIP_2: POS+/-DIR
TIP_3: POS+/-ROT

Thanks a lot, that confirms some of my assumptions.

So, if I'm correct:
TIP_1 is actually position of the grapple point.
TIP_2 defines a vector out of TIP_1, that sets grapple's direction
TIP_3 defines a vector out of TIP_1, that sets grapples rotation.

I'd have one more question... do these two vectors have to be super-exactly 90° to each other?

It seems to me, that when it goes less then 90°, the attached satellite disappears and the game crashes. When it's more than 90°, it makes those weird rotations. I'm trying to achieve a directional vector, that is rotated by two axes, so neither TIP_2 nor TIP_3 can be set with absolute accuracy. It'll be possible only to reach super-close to 90°, and that might end up in disappearing or rotation anyway.

---------- Post added at 18:26 ---------- Previous post was at 17:45 ----------

OK, so i took the easier way.:shifty: I rotated the arm wrist's transport position by 2.5°, so i don't have to rotate the directional vector by two axis, just by one. Now it fits perfectly.:thumbup: Anyway, thanks to both of you for help!

 

[Cizurator]

Another question, just a minor one: I have succesfuly set MFD displays for my virtual cockpit. The MFD display groups were required to be rectangles with four vertices and two triangles - this was mentioned both in spacecraft3 readme and Orbiter SDK. But requirements for HUD group are not mentioned. Is it the same case like MFD? Does it have to be a rectangle?

Thanks in advance for any information on this

 

[Cizurator]

Aerodynamics finished! Only now i found that great possibility to set different lift values for different AoA regimes (VAIRFOIL_LIFT_1,2,3...) and drag values (VAIRFOIL_CD0), all that with spacecraft3 aerodynamics. I have achieved to set up following abilites, which IMHO are quite appropriate for a 15-ton conventional shuttle:

1) self-stabilized aerobraking with AoA 30°, never exceeding 2G
2) transition to steep dive with AoA 0-5°
3) final approach with AoA 5°-10°
4) smooth landing at 80-90 m/s with AoA 8-13° on Makatea RWY

In the end, i felt a bit like landing the Atlantis...:thumbup:

 

[Lmoy]

Are you planning on implementing destruction simulation?
Also: reentry heating effects?

 

[Pipcard]

That can't be done with the Spacecraft3 module...

 

[Cizurator]

That can't be done with the Spacecraft3 module...

Exactly...
Well, as always, there would surely be a certain way to do it with an animation. I can imagine the reentry shield changing color, a long stream of swirling hot plasma, sparks falling off, whatever my heart could ever desire, but that would be just... a fixed, non-situation-responsive animation. The same with destruction.

 

[Lmoy]

Can't be done with SC3? Makes sense. Sorry, I'm not very familiar with the capabilities and limitations of SC3! Those aren't important bits, of course, I was just curious. This is looking really lovely, overall.

 

[Cizurator]

Thanks!
I guess we all strive for every bit of perfection for our addons, but only as far as our abilities allow us. For those with knowledge of programming, there's practically no limit...

But, to be honest, even with Vinka's great spacecraft3 I still keep finding new ways. I wish Vinka had continued to expand the SC3. I bet many addon-makers like me would go crazy for any new possibilities...

 

[K_Jameson]

The main advantage of Spacecraft3, for me, is the stability and compatibility of the system. With Sc3, sure, you has limited possibilities and this is unacceptable for many developers, but, when your addon is done, and unless macroscopic errors, you are sure that everything will work. You don't have to spend weeks in debugging: reading tons of pages of complaints from users that has found every sort of microscopic bug, then fix it, upload a new package, read about reactions and new hidden bugs, re-fix it, re-upload... over and over and over again.
The immaginative developer can be more happy to spend that time working on something else.

 

[Cizurator]

Maybe there's one quite important advantage of independent programming. When you start something new and big, aware of how much time and effort you'll have to invest into a single project, you make sure that the plan is good enough, and that the final product will be worth of it. The SC3, in comparison, requires only little effort, and therefore doesn't make you do your best, i think.

Look at some of my old SC3 projects. I was able to create (for example) a brand new space center, a brand new launch vehicle and a brand new spacecraft - all that within a few weeks. But today i look at it as a low quality "addon-fodder". Easy come, easy go. "My own addon on OrbitHangar, hoorrray!" Good enough for beginnings, but times have changed.

Or have they? I'm still stuck with SC3. Well, at least now I'm trying to do it more properly