Project Gemini-Titan 2 for Orbiter 2016

[Urwumpe]

Only slow progress this week, my family demanded more time from me. But at least a small amount of progress.



Currently doing some test flights with the second stage to find the right set of steering constants for the second stage. Once this is working acceptable, I will go on with integrated tests of both first and second stage.

 

[Urwumpe]

OK, at the end of the night, I have at least a "good enough" TARS closed-loop guidance, which aims for a 300 x 169 km orbit. Still some things there that I don't like, but since the quick and dirty test scenario is also not really the best start for test flights, I can accept it.

Next: Integrated flights of second stage and first stage, with second stage doing the guidance.

And then I can go on refactoring the spacecraft and putting it on top of the stack.... and finally approach the end of the big architecture changes.

 

[Urwumpe]

And now, its getting towards flying the full ascent:



Now its time to let the second stage handle all the guidance, which is necessary since the fixed open loop first stage guidance (hardwired into the TARS programmer) is still active for the first seconds of second stage flight and continues even during separation. Also, a lot of duplicate code (primary autopilot, malfunction detection system, secondary autopilot) can be avoided this way and the responsibility is clearly defined.

 

[4throck]

Cool! From the separation videos I don't notice any special behavior from the first stage after separation.
But it seems relatively stable, perhaps due to the guidance you mention

Here's a real time view (quite fast) with fisheye perspective correction:

Might be useful for comparison purposes.

 

[Urwumpe]

Cool! From the separation videos I don't notice any special behavior from the first stage after separation.
But it seems relatively stable, perhaps due to the guidance you mention

Here's a real time view (quite fast) with fisheye perspective correction:

Might be useful for comparison purposes.

It should be almost completely inert at this point, its more important that the second stage keeps the same pitch rate as the first stage during the really short separation.

If you look for a treasure trove full of great Titan II stuff, look at this museum and its Youtube channel, I really recommend it:

AFAIR, the overlap from first stage guidance into second stage flight had been picked to give the guidance computer on the ground (Borroughs) enough time to measure the state vector with all needed radar stations.

 

[4throck]

Cool stuff!

 

[Urwumpe]

OK, maybe I overestimated the possible gimbal range of the first stage engine a bit. The telemetry of the GLV covers +/- 1.25 inches of travel of the actuator.

I assumed +/- 8° but using the (coarse) geometry of actuator and thrust chamber, I get merely +/- 5° of travel out of the first stage engines.

The second stage has even less actuator travel range.

 

[n72.75]

@Urwumpe, I'm still interested in working on this btw, just been very busy with life.

 

[N_Molson]

The second stage has even less actuator travel range.

That makes sense, the most dangerous part of the flight in terms of controls is early ascent, where dense atmosphere and huge inertia at launch (because of the fuel mass) make everything more difficult. Also, the roll program mixed with gravity turn is usually quite demanding. The second stage gimbal, provided the separation is clean enough (well on Gemini-Titan it was... spectacular...) has little to do, only minor corrections in near-vacuum, where there is nothing like a wind gust.

 

[n72.75]

Taking a look at this again. I think we may need to work on our .gitignore a bit.

NASSP's looks something like this, and uses exceptions.

# CVS global ignores
Release
Debug
RCS
.svn
SCCS
CVS
CVS.adm
RCSLOG
cvslog.*
tags
TAGS
.make.state
.nse_depinfo
*~
#*
.#*
,*
_$*
*$
*.old
*.bak
*.BAK
*.orig
*.rej
.del-*
*.a
*.olb
*.o
*.obj
*.so
*.exe
*.Z
*.elc
*.ln
*.hgtags
core

# Project ignores (converted from .cvsignore files)
!/Config
/Config/*
!/Config/ProjectApollo
!/Config/Collision/ProjectApollo
!/Doc
/Doc/*
!/Doc/ProjectApollo - NASSP
/Html
!/Html/Ncpp.chm
!/Html/Project_Apollo.chm
!/Sound
/Sound/*
!/Sound/ProjectApollo
/Orbitersdk/*
!/Orbitersdk/samples
/Orbitersdk/samples/*
!/Orbitersdk/samples/ProjectApollo/
!/Meshes/
/Meshes/*
!/Meshes/ProjectApollo
/Install
!/Script
/Script/*
!/Script/ProjectApollo
/Textures/
!/Textures/ProjectApollo/
/Scenarios
!/Scenarios/ProjectApollo - NASSP
*.vcxproj.user

# Stuff that wasn't previously ignored
/Constell.bin
/Constell2.bin
/D3D9Client.cfg
/Device.dat
/Flights/
/Images/
/LuaInline.dll
/LuaInterpreter.dll
/Modules/
/Orbiter.cfg
/Orbiter.ico
/Orbiter.log
/OrbiterSound_Log.txt
/Orbiter_NG.cfg
/Star.bin
/Textures2/
/Utils/
/dxdiag.log
/install.log
/keymap.cfg
/keymap2006.cfg
/lua5.1.dll
/lvlog1b.txt
/lvlog5.txt
/lvlog.txt
/msvcp71.dll
/msvcr71.dll
/patch.txt
/pkey.ppk
/readme.txt
*.log
*.launchpad.cfg
XRSound/
/ikpFlac.dll
/ikpMP3.dll
/TrackIR.cfg
.vs
/RTCCDebug.txt

I can fix this. Trying to ignore things locally is causing other issues for me. the first of which was fstream.h -> fstream and the rabbit hole got deeper from there.

There are a couple of weird issues with compiling under VC2019 V142

I get this error in debug mode " '/ZI' and '/Gy-' command-line options are incompatible"

 

[n72.75]

@Urwumpe

Do you get these build warnings/errors? I don't want to go changing a bunch of includes and namespaces if I just did something dumb here.



I have a branch for testing some file-reorganization, but I need to build first to check.

The meshes we have would make great placeholders for separating the vessels into stages and moving past multistage.

 

[Urwumpe]

I also had a lot of those, that was one of the reasons why I decided to quarantine all the multistagex stuff there and go on with a cleaner approach.

When it came to doing backend work, I just got stuck there, its harder to do late at night. :/

#include "fstream.h" is for example old C-style syntax, while the C++-standard code is #include <fstream> and having everything in the std namespace.

 

[n72.75]

Well good to know I'm not too far off track. And it provides some fairly concrete direction for what to work on first.