Project Soyuz 7K-T Custom

[diogom]

Hey all,

Time to bring to light a project I've been working on since around April:

Soyuz 7k-T Custom

Latest version download:

https://www.orbiter-forum.com/resources/soyuz-7k-t-alpha.5470/

VC:



Taking on the legacy of previous iterations of these ships, I figured I'd pick this up to learn how to build an addon from the ground up as a personal project, and if I managed to take it far enough, eventually open it up to the community. I think it has progressed enough now.

This is a fully custom .dll implementation of the Soyuz 7K-T version, which I chose to start with since it flew for the longest time and didn't have the solar panels to complicate matters. My intention is to make this relatively systems-complete, taking into account both my skills and time, and the scarce detailed information available.

A summary of the main current features:

• SKDU main corrective engine system, with main (SKD) and backup (DKD);
• Both RCS modes: DPO (98 N) and DO (9.8 N), arranged as seemed logical to minimise torque and drift, taking into account the actual thruster positioning;
• Two manual control schemes for RCS: RO (discrete angular rate commands) and Pulsed-RO (fixed angular rate increments through short thruster pulses);
• Orbital Orientation (Prograde + Horizon level) and Solar Tracking Autopilots, based on the included Ion, IR and Sun/Star Sensors;
• Experimental Igla autopilot, with limited range and testing conditions - integrated with a custom Salyut 4 also running Igla (Passive mode), working mostly for a starting distance just under 5 km;
• Detailed and function-ready Virtual Cockpit - Main Panel + Both KSU side panels - some functionality implemented, all in Russian, at some point planning to offer an English version;
• Module separation, 20 degree AoA reentry and basic landing sequence (main chute only).

My immediate priorities would be more VC functionality, as for now a lot of the displays are blank textures, integrating the KSUs, a basic battery system and a go at the gyros/rate gyros. The SA interior is pretty basic but for the time being it's not a priority. Many things need refining still.

With castorp's blessing, I'm using the OctoberSky meshes and textures (https://www.orbithangar.com/showAddon.php?id=c964ab64-ff44-47a2-ab94-fee98570d50a) for the exterior models with some small edits, largest of which is probably the fusion of Salyut 1 hull and Salyut 4 solar arrays to make Salyut 4 proper. Only the VC meshes/textures are my own for now. Note: thermal blanket green (hot topic as I remember it) was changed by me and is based on surviving Almaz hardware, recently (2011) photographed by Anatoly Zak. However, nothing is set in stone, and this is only my assumption that materials would be the same or very similar.

Launch is integrated with Igel's Soyuz FG.

This is made for Orbiter 2016 only, but currently only working in D3D9 due to an issue with oapiGetTextureHandle returning NULL and eventually causing a crash with the default client. Anyway, the visuals are much improved in D3D9 with the Metalness shader so I'd still recommend it otherwise.

With this thread I intend to share progress and hopefully open it up to discussion. I'm under no illusion that this is as polished or as efficient as it could be, since I've just been learning every aspect of it along the way. Historical documentation can also be contradictory, vague or confusing, adding to the challenge.

I have no expectations for a full release yet, whatever that would look like, other than "Tuesday", but I plan to put together some WIP usable versions on here from time to time as it progresses. As it turns out, the timing of this coincides with transitioning from stuck at home summer holidays to a return to in-person semester and thesis year, so progress will be slower, but I'll find time for it.
Currently I'm in the process of polishing off a few things and mostly deciding on an initial layout to the KSU command matrix. For now, I'm compiling the information I have and thinking it will be a mix of both sources, 7K-OK and 7K-TM. This way some basic functionality can be added before the first release.


Looking forward to share more

 

[n72.75]

This looks fantastic! Can't wait to take it for a spin.

 

[Sbb1413]

Wow, fantastic! It looks we have three Soyuz add-ons for Orbiter 2016. I would like to make a list of real-life vessel add-ons working in Orbiter 2016, vaguely based on the now-stalled Operation Spring Cleaning aimed for curating a list of add-ons in Orbiter Forum.

 

[diogom]

Alright, back on the Signal Matrix. Courtesy of https://www.orbiterwiki.org/wiki/Sirius-7K_IDS and its respective sources, and the ASTP doc, I've arrived at an initial version with the stuff 7K-OK and 7K-TM, respectively, apparently had in common:



Only one column is selected and thus displayed at one time, the first 12 rows have two buttons each allowing for on/off commands, and the rest I presume would just be for execution/event monitoring.

Question is, how to fill in the rest. The 7K-TM version had the APAS, and the translations from the ASTP doc seem to support that, while -OK would have been a more primitive version of SSVP. The "C" column also is only named and populated in the -TM source (and the Soyuz 35 cockpit, which was my main source visually, also supports this), and it seems a lot of docking related commands/signals from the "Ж" column were moved to it. Which is why there's barely any docking related things present in the above version.

It seems logical to give -TM the priority, since it was concurrent with 7K-T (and derived from it, even). The problem is the presence of the APAS, but in that case I'll default to the earlier SSVP version. If something appears to be related to solar panels, well, better off left blank. Also important to keep in mind that many of these things will probably never have a use in-sim other than visual accuracy. The same approach can probably be applied to the Electroluminescent Signal Matrix on the main panel, both versions also differ but are the only sources I've found.

The good thing is some of the more basic functions can in theory already be controlled from this: Select DPO/DO, the manual control modes, and possibly the Vzor view orientation. That should be a good basis to start off on. Animate the buttons, and start planning out the code logic.

 

[4throck]

I'd say focus on what's already simulated like the DPO/DO. Makes perfect sense to use those systems using the correct panels.

As for the VC animation, you can base it on reality and model a cylinder like this:

Then it's a simple rotation animation!

 

[diogom]

Agreed, anything else can just be added to the textures and coded later.

Right now it's set up for an instantaneous texture swap on a single panel, depending on the column button pressed. The cylinder itself should be two clicks on Blender, integrating it (getting the vectors, coding the transitions, etc) would be the more time consuming part. I'll have a look next week if I can get a few things out of the way during the weekend, see if things don't have to change around too much.

 

[diogom]

Had some time and did the cylinder thing:



Cut a whole on it too without messing up the texture, so it's kinda sunk into the panel face. And at least this way it only texture-swaps for the signals lighting up. On that front, not quite sure what colour they would light up as. Maybe yellow and/or green like the ELS?
Fun(?) part next, getting it all to do things.

 

[jacquesmomo]

???

 

[n72.75]

That is very impressive.

 

[4throck]

Looks real !
Great work!

 

[diogom]

And that's that:

On this front, I reckon all that's left is saving/loading the currently selected column to/from the scenario file. Might adjust the speed later, small thing but not sure what it would have looked like.

Next step, making a decision on the signals' colour, texturing them in and then the on/off buttons for DPO/DO and RO/I-RO.

 

[diogom]

Well, it's Tuesday (in some places, still).

DPO/DO and RO/Pulsed-RO on the KSU is ready enough. Documentation is updated, and just confirmed launch to docking has not been somehow broken. Think the first version is ready for anyone who would like to try it.
Edit: trouble with the attachment, here's a Drive link:


Orbiter 2016 only, with D3D9, as the VC is broken in the inline client (still no clue what's happening there). Also, for some reason, the BO has no texture on the inline client, event though it works just fine with D3D9. Might be something with the file name.

Launch will require Igel's Soyuz 1.2 and its requirements. Do give the PDF a look as it explains what's included and how things work, but these are the essential bits for a straightforward flight:

• M or KSU for swapping between DPO and DO;
• F or KSU for cycling the manual control mode (RO, Pulsed-RO and OFF);
• L for approach lights;
• Don't forget to deploy the docking probe (G);
• I to activate the Igla autopilot (max range of 6 km);
• In RO mode, pressing the desired Numpad key fires the thrusters until a fixed angular rate is reached, and releasing the key cancels that rotation. Control keys are as default, it's just the handling that changes.

I've also included the current translated KSU matrix, that should be the guide to finding your way around the panel.

My advice, nice and slow approach (though within two days) so the closest approach is < 5 km and relative velocity is low, use no more than 1-2 kg of DPO on small corrections before the final approach, especially when using the Igla docking ap. This should be harder since Salyut would have orbited around 350-ish km, so it's currently too low in my scenario. But so far it has simplified testing. For the main engine, I've found the main limiting factor is the de-orbit burn fuel requirement.

Concerning Igla, my working procedure has been: approach as normal to just under 5 km (Salyut has an IDS frequency), use the main engine to null relative velocity, engage Igla and let it (hopefully) do its thing, no input required. I managed today to dock with 26 kg DPO remaining. You can monitor it from the VC on the IRS (bottom right), but the info will also be displayed on the HUD (most of it is for debugging and temporary). The advantage in Igla is having Salyut point itself towards the Soyuz. On a manual approach, it might be useful to jump on Salyut and manually orient it towards Soyuz, since Soyuz's manoeuvring capabilities aren't great. Or not, for added challenge.

During re-entry, aim for an AoA of 20 degrees for max lift, and in theory, control it by rolling. It should stabilise at 20 degrees, but you do need to initially pitch it there manually. Parachute deploy and landing burn are automated, but is very basic for now and needs further tuning. I have to be honest, my focus has been on the orbital phases of flight.

Good luck

 

[jacquesmomo]

Well, it's Tuesday (in some places, still).

Hello
I just downloaded your addon.
I try as soon as possible (at the moment I don't have a lot of free time) and I'll tell you what I think !!
thanks to you

 

[Gargantua2024]

Well, it's Tuesday (in some places, still).

This is great! Imho much better than what I did on my own version, which is technically a direct port of the great 2010 addon into O2016

 

[diogom]

Thanks guys!

Had a small break to focus on other things, time to pick this back up. I reckon I'll get to re-reading what there is about the gyros and start sketching out the implementation in Orbiter. Other than the inertial stuff itself, I'd already noticed there's information in there to tune the autopilots that are already working, for more accurate angular rates and manoeuvre sequences. This plus the batteries seem like the best next moves to me.

 

[diogom]

Cleaned up the digital unit in preparation for functionality:



Remaining SKDU Delta-v (bottom right counter) is at least ready to be displayed, as is the bottom electroluminescent display to signal backup engine operation.

Getting a better understanding of the two gyro systems, though it's kinda vague exactly how they worked and what they did. I might take some creative license until if something more concrete shows up. Anyway, re-tuned the autopilots for the BDUS (3 rate gyro system for X, Y and Z) documented 0.45 deg/s manoeuvres, as they would use the Ion, IR and Sun sensors to get orientation data relative to the Earth/Sun but would use the BDUS for angular rate commands. Also tied BDUS activation to the KSU panels (simple on/off, just guessing here).

Next steps: Delta-v indicator and attitude hold APs (horizon level config, not inertial).

 

[WolfAngriff]

Wow... Very impressive ! I can't believe that this beast will be flyable one of these Tuesdays. With Igel's rockets, maybe with MaxBuzz's Mir Station... Short nights are coming !

 

[diogom]

Small update up:


Haven't had as much time as I would like, but anyway, wanted to put something up since VC now works with the default O2016 client. It was an issue with the DDS format, thanks to DaveS for the DXTEX.exe fix over on the Better ISS thread.

Meanwhile,

• the digital unit was updated with the remaining Delta-v counter;
• retrograde orbital orientation ap introduced;
• orbital orientation ap configuration (prograde or retrograde) and activation tied to the KSU commands;
• BDUS (rate gyros) activation is now required for the orbital and solar autopilots.

Also began populating the empty spaces on the KSU matrix with the Apollo-Soyuz reference, will defer to it except where it relates to the APAS docking system.

 

[thermocalc]

Hi to everybody, I am new to this addon.
I just downloaded and made a new Orbiter 2016 installation to test it.
BUT I have an issue from the start ... I just loaded the docked scenario and get into the VC but everything is dark ... is there some sort of illumination inside the capsule?
I think to have not read about it in the manual provided in the doc folder.
thanks and best wishes to continue the hard work...now that I discovered this addon I will keep my eyes open on its developments...GREAT JOB GUYS OUTHERE

 

[diogom]

Hi thermocalc,

Are you using the stock graphics client? There is a spotlight inside, but it doesn't do much unfortunately. At best, the lighting should change depending on orientation relative to the sun, on the daylight portions. I'm afraid I haven't figured that out yet, whether it's on my end or the graphics'.

If that's the case, I would highly recommend the D3D9 graphics client if possible, there I've managed to get consistent lighting, among other improvements. If already on D3D9, don't forget to turn on 'Local light sources' on the Visual Effects tab.

Cheers