Project Space Shuttle Vessel

[GLS]

GLS: Is there anyway to tweak the atmospheric FCS gains? The orbiter is very sensitive to inputs in pitch but roll response is almost nonexistent. I have to put in a near full command in the roll axis in order for the FCS to execute any sort of roll while pitch is so sensitive that you could breath on the RHC and it will respond.

The AerojetDAP should be pretty much like the real thing, both in logic and values (except for the "cheating" in the I/O). I have more data to look at, and some things will likely change as a result, but it won't be anything revolutionary.
Actually, the roll is pretty unstable around Mach 2 or so, as it was in real life, so it might just be lazy like that at lower speeds.

The physical properties and/or the aero might be wrong, but I never found anything obviously wrong.

The joystick input should work correctly, as I changed to the correct Orbiter function to get it... but I have no joystick to test. Anyway, the inputs received in the GPC are visible in SPECs 25 and 43.

 

[DaveS]

The AerojetDAP should be pretty much like the real thing, both in logic and values (except for the "cheating" in the I/O). I have more data to look at, and some things will likely change as a result, but it won't be anything revolutionary.
Actually, the roll is pretty unstable around Mach 2 or so, as it was in real life, so it might just be lazy like that at lower speeds.

The physical properties and/or the aero might be wrong, but I never found anything obviously wrong.

The joystick input should work correctly, as I changed to the correct Orbiter function to get it... but I have no joystick to test. Anyway, the inputs received in the GPC are visible in SPECs 25 and 43.

The region I'm having the issues with is the subsonic region, when CSS is supposed to be used. I'll check with the SPECs to see what they show in so far as physical outputs are detected.

 

[GLS]

Quick update!
APDS avionics work is pretty much complete, with just 1 or 2 issues left to work. It follows the original (Mir) implementation, so the auto docking sequence works and will do all the actions needed after capture to bring the vehicles to a "hard-dock". This sequence was eventually disabled for the ISS (not 100% confirmed yet), due to the dampers not releasing when commanded, which messed up the ring retraction. A manual procedure, in the Rendezvous checklist, was used instead. I haven't done a complete check, but this manual procedure should still be possible to follow, which stops the auto sequence, so pretty much both methods are available.
In the future, the change to disable the auto sequence will be put in the logic, thus creating the ISS version of the APDS avionics, and an option will allow the user to pick which APDS/ODS is to be used.

In the flight deck, the "Docking System Power" panel is now the one introduced for the ISS missions. The previous one was a mix of the original (Mir) and the ISS version, and was missing an empty section at the bottom, which meant it ended up vertically stretched. Currently this is the state of things:

The missing details will be added in the following days, along with finishing the "power cabling". No support yet for vestibule pressurization, pyros, SPEC 167, or "remote" APDS control.

So, a mixed set of parts for now (btw, the APDS outside is the ISS version), but it is coming together and should still be a big improvement, and it should also allow both APDS/ODS versions to exist in the future (I could everything now, but it will just delay the release even further).
One related issue to investigate is the position of the overhead hatch, which seems a bit too far up, decreasing the CL camera view.

 

[GLS]

Release Tuesday is here!!!

Somewhat later than expected, but SSV v1.8 has now been released! https://github.com/GLS-SSV/SSV/releases/tag/v1.8
The big item is an improved ODS and control panels, plus an implementation of the 1001 relays that controlled docking and undocking, which improves the "docking experience". Rounding off the package, there are also some small mesh corrections, improved scenarios and documentation.

Work on v2.0 will now return to full throttle, with the removal of the MDU stuff from the GPCs, leaving the display logic there independent of the MDUs, and eventually CRTs.

 

[DaveS]

Would it be possible to incorporate a damper for "nervousness" of the A2 LINE OF SIGHT RATES display? Also, it seems like the RR half of the Ku band system doesn't save/load a tracked target, forcing you to redo the initial two steps of the KU OPS cue card of the RNDZ FDF to reacquire the target every time you re enter the scenario.

 

[GLS]

Would it be possible to incorporate a damper for "nervousness" of the A2 LINE OF SIGHT RATES display?

The needles are already calmed down... but it's possible to improve that, at the cost of responsiveness.

Also, it seems like the RR half of the Ku band system doesn't save/load a tracked target, forcing you to redo the initial two steps of the KU OPS cue card of the RNDZ FDF to reacquire the target every time you re enter the scenario.

This area is a bit more fundamental, and is unlikely to see any work until after v2.0, when changes will be made to have the antenna connected to the GPC.

 

[Urwumpe]

The needles are already calmed down... but it's possible to improve that, at the cost of responsiveness.

You could implement a infinite impulse response filter there, these are very easy to implement and can act as a low pass filter to reduce the amount of clutter, without a cost at response times.

 

[DaveS]

The needles are already calmed down... but it's possible to improve that, at the cost of responsiveness.

Not what I am seeing:

 

[DaveS]

Here's improved ISS Radar Test scenario which has the orbiter properly on the R-BAR at 600 ft rather than the weird offset that the original has.

 

[jarmonik]

Hi,

I would need to be able to compile this project to debug the issue with moving docking port while docked. I get a lot of errors like "fatal error C1083: Cannot open include file: 'Orbitersdk.h': No such file or directory". Do I need to install the project in some specific location or edit a configuration file somewhere ?

 

[GLS]

Hi,

I would need to be able to compile this project to debug the issue with moving docking port while docked. I get a lot of errors like "fatal error C1083: Cannot open include file: 'Orbitersdk.h': No such file or directory". Do I need to install the project in some specific location or edit a configuration file somewhere ?

Hi!
The project should be located in the Orbiter base directory, and the code will be in the "Orbitersdk\Space Shuttle Vessel" folder. The module dlls will end up in the correct folders when building.
OS4 or 5 is needed, and the lib and header file will need to be moved to the Orbitersdk folder structure.
Also, use the "newOSFS" branch, as that is the one with the changes for the new Orbiter.
For docking, use the "Space Shuttle Vessel\Historic missions\STS-126\STS-126 docking with ISS Nov 16.scn" scenario.

 

[jarmonik]

I managed to compile SSV and reproduce the very fast spin shortly after docking. OS4 works but OS5 has some issues.

 

[DaveS]

I managed to compile SSV and reproduce the very fast spin shortly after docking. OS4 works but OS5 has some issues.

Shouldn't all of the OS specific code be replaced with their XRSound equivalents given the closed source nature of OS and the fact that there's no need for it anymore as XRSound now comes included with the base install of OpenOrbiter?

 

[jarmonik]

Here's a modified ODS code for better docking. Only works with PR #445

 

[GLS]

Here's a modified ODS code for better docking. Only works with PR #445

Thanks!
I didn't expect the "soft" vessel realignment, but it looks good. Sadly, the ring reaction to the docking forces is way too complex to handle, both the physics as well as the 6-degree of freedom ring animation, that's why I had absolutely nothing done for that...
I want to look at the changes with calm, and move the static variables into the class, but that should be it. Thanks again!

 

[jarmonik]

It might be good idea to change the linear interpolation to hermite interpolation since it gives more natural feeling for a movement since we are dealing with heavy objects. With "herp" movement starts and ends slowly. With "lerp" movement is instant.

VECTOR3 herp(VECTOR3& A, VECTOR3& B, double x)
{
    x = max(0, min(1, x));
    double y = x * x * (3.0 - 2.0 * x);
    return A * (1.0 - y) + B * y;
}


double fS = 1.0 - fSettleTimer / 5.0;               
VECTOR3 dir = herp(sdock_dir, DOCKING_PORT_DIR, fS);
VECTOR3 rot = herp(sdock_rot, DOCKING_PORT_ROT, fS);
VECTOR3 ref = herp(sdock_ref, DockPos, fS);

 

[GLS]

... so, where were we?
Back to SSV after a break to help Orbiter. Still have to merge the docking update, and check for any other loose ends, so that a version for the new Orbiter is ready to come out when time comes. But in the meantime I want to move the display stuff along a bit more. A few weeks ago I actually took a Sunday off from the LaTeX work and returned to SSV and got to this point:


It doesn't look like much, but actually the old method of showing the symbols (copying from a bitmap) has been replaced with the more standard method of "creating a font and outputting text". Amazingly, I got the grid layout to work on the first attempt!!! This method will also allow for the symbols to be rotated, which is needed, e.g., in the VERT SIT display.
The "big X" and the "POLL FAIL" outputs are also new, and eventually will show up if the user doesn't have a GPC assigned to the IDP.

 

[chevelle505]

Glad to see this project getting some love..absolutely amazing GLS, thank you for your dedication to this!

 

[chevelle505]

Quick question, is there a timer I’m missing that shows time until touchdown on landing (assuming the auto pilot is used)?

 

[DaveS]

Quick question, is there a timer I’m missing that shows time until touchdown on landing (assuming the auto pilot is used)?

No, there never was. If you talking about the notes by the PAO, then that was pretty much a ground function only.