Project Soyuz 7K-T Custom

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
And an important lesson was learned in cutting all thrusters after soft-dock. Speaking of which, I should probably disable that on the manual control.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Decided to go on a wild goose chase: allocating and deallocating properly. Both vessels have some issues there, since I've been winging it from the start. Known for a while, but the "crash on exit" thread alerted me to it.

Got Salyut under control, but can't pin down what's wrong with Soyuz. Not really doing much that's different between the two vessels in terms of resources, besides some texture loading which gets oapiReleaseTexture'd on the destructor. Deleting all the MGROUP_TRANSFORM* I create too.
Got the whole inter-class communication thing (for Igla) out of the way by removing any reference to the Salyut4 pointer, same with using PSTREAM_HANDLE and LightEmitter since that's two of the other differences. Global variables are the same consts and statics between the two. I've been following some other existing source code and don't see anything that doesn't work there, but obviously something's out of place... Something to do with the VC, maybe?
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Got it, turns out it was the oapiReleaseTexture. Guess I need to read up on when that works and doesn't. Onwards to more fun things.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Came across an actual photo of a 7K-T, courtesy of Oleg Artemyev's IG (his Youtube channel tends to be interesting):
1649976075667.png

Also seen on Soyuz 3, with a slightly different shape:
1649976320522.png

So naturally, having the layout of the RF shielding for Igla as confirmed as it will probably ever be (the best documented one visually, 7K-TM, didn't need it), spent the afternoon in Blender:

1649976277990.png

Might take some getting used to.

Been doing a few different things, and the last I'd like to get done for this batch is the inertial attitude hold. Attitude hold for the orbital orientation is working, that one is simple enough, triggers automatically after initial alignment. For inertial though I still need to piece together what the sequence of commands would have been like to use it, including the black box that is interacting with the rate gyros. The Soyuz-TM manual cleared up some things overall, and with the context of the mostly (96%) translated 7K-TM KSU matrix, been making some better sense of the ASTP-era document.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
So, TL;DR inertial is a rabbit hole. Ramble ahead.

As usual the information available is kinda vague and confused. I've been assembling an idea of where the wires connect with the different sources, and within each source, looking at how the systems interact. The sequence of commands involved in the inertial stuff is a bit clearer but I'm still missing a few pieces. Posting in case it's interesting enough.

Basically there are two systems to keep track of attitude with:
  • There's the gyro system: two gyroscopes, two gimbals each, used simultaneously, which give attitude angles. Still not clear on if it can give angles for the three axes (having two of them at once equivalent to a single three-gimbal?), but it only allows manoeuvres in roll and yaw. Regardless, there is a reference to holding attitude in pitch as well. Cage them, establish the attitude to take as a reference, uncage the gyros so they get a fix on that reference for the attitude to hold.

  • Then there's the BDUS unit: three one-gimbal rate gyros, which either give angular rate for all axes, or can be integrated (rate over time gives absolute angle change) to give angles in three axes and allow manoeuvres in pitch, roll and yaw. It is said switching this integration on can be done manually, problem there is I'm not quite sure which command in the signal matrix corresponds to it. The "INTEGR." one refers to the accelerometer, which measures acceleration on the longitudinal axis for main engine burns, and so is unrelated. Other than that, the documentation is vague and the commands aren't quite explicit.

It is said inertial attitude hold and manoeuvres can be accomplished with either system (gyro with BDUS rates, or just BDUS with integration), only with varying tolerances, angular rates and sequencing.

I've been trying to cross-reference the 7K-OK (first-gen) and 7K-TM documentation (second-gen, along with 7K-T), and trying to make sense of the sequence with the program timer for clues. Both sources differ, but commands seem to roughly align between the two displays in terms of order. For instance, for 7K-TM (no individual programs are documented AFAIK):

1651205031608.png

On the right column are individual commands which are activated automatically in order according to the time scale in the middle (in minutes), but supposedly can also be toggled manually on the KSU just in case. There is a direct reference to "Integrate (B)DUS" (which is missing from 7K-OK below), "Inerts. 1/2" I believe to be related to the "Prepare Inertial 1/2" commands on the KSU (gyro power on/run-up kind of stuff, caging, not sure), and also to be analogous to "ГБ-А" and "ГБ-Б" in 7K-OK (@Urwumpe did you ever find out what "ГБ-А" and "ГБ-Б" refer to?). Then there's "Inertial Orientation" which does correspond to a command directly and should be the final activation of the attitude hold.

The 7K-OK doc provides a clearer example, in this case for the de-orbit program (Spusk 2):
1651205430521.png

First, BDUS is activated (angular rates are always needed), followed by establishing orbital orientation (prograde), then "ГБ-А" and "ГБ-Б" come in with a 10 minute separation. SDKU main engine is pressurized, accelerometer (Integr.) is turned on (so the engine can shut down at a pre-set measured Delta-V), SUS (descent control) is turned on, and at 60 minutes the SKDU is fired, simultaneously with activating inertial attitude hold so that Soyuz maintains the intended burn vector. Interesting to note here it is directly "Разарретир - Uncage", which to me suggests the gyro system is used. Not sure if that, plus the absence of an "integrate BDUS" command, indicates in the first Soyuz generation there was no BDUS integration or it was not prefered, and later in 7K-TM, there was a change in procedure.

The bottom line is, Orbiter implementation-wise it probably doesn't matter much which system is used if only attitude hold is considered, and either way I think I've pieced together enough info for manual switching between using the gyros or BDUS (there's a "Gyro Assembly (Rate - Free Gyro)" command), and I might proceed with at least the simple "on/off" functionality. But still dunno where that BDUS integration is supposed to be. My best guess is either "Select 3-Axis Orientation" or maybe "BDUS Filter".

The plus side is I also learned how the program timer display worked and getting it into Orbiter eventually seems doable, at least for main engine burns.

For reference, my current reconstructed ASTP command matrix, which I'm favouring as it should be closer to 7K-T in some places:

1651208440981.png
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,845
Reaction score
2,581
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
GB-A and GB-B are at K15/16 and K17/18, in your case "Preparation for Inertial I" and "Preparation for Inertial II".

I am 95% sure, it refers to the KI-38 gyroscopes, which got replaced by a single unit (SG) on Soyuz-T, which can mean "free gyroscope"or "powered gyroscope".

The GB acronym is completely unknown in Soyuz-TM.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi "diogom" ... nice to see your steady progresses ... keep my fingers crossed for your endevour .... take care.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,311
Reaction score
3,290
Points
203
Location
Toulouse
Soviet documentation is hardcore stuff but it seems you're on the right path, that's good work ! ?
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
GB-A and GB-B are at K15/16 and K17/18, in your case "Preparation for Inertial I" and "Preparation for Inertial II".

I am 95% sure, it refers to the KI-38 gyroscopes, which got replaced by a single unit (SG) on Soyuz-T, which can mean "free gyroscope"or "powered gyroscope".

The GB acronym is completely unknown in Soyuz-TM.

Yeah, even in ASTP era it's nowhere as far as I can tell. I'm guessing it would be some variation on "Gyro Blok", maybe.

Probaby safe to assume "Prepare Intertial 1/2" still refer to the KI-38, whatever it is those commands actually did. Best I can probably do is treat them as simple pre-requisite black boxes.

Another semi-related curious difference over the years is in the digital unit, for the programmed attitude manoeuvres, where 7K-OK and 7K-T (at least Soyuz 35) seem to deal in azimuth and elevation of the Sun, βs and γs, and two local-reference angles, αх and αу. While the ASTP doc has it as only three local angles, αх, αу and αz. Best part is the -OK doc has an actual photo of this latter version, right next to the diagram of the former. Since 7K-TM was kind of the stepping stone to Soyuz-T, guessing the three angle version was the more "modern" take but they never bothered updating it on the others. And to be honest, dealing in angles relative to the sun doesn't seem as useful in LEO.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,845
Reaction score
2,581
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
The biggest difference between the old OK-era Soyuz and the more modern T to TMM era is the switch from an analog control system to a digital one. In the old OK, you really just switched on analog control blocks and had only minimal relay-style logic installed. From Soyuz T on, pretty much everything inside changed. Maybe some aspects of the life-support system stayed the same, the outside shape did not see drastic changes, but the GNC stuff is completely revised.

If its about KI-38, you can treat the commands like that:

enable: uncage the gyroscope
Disable: Cage the gyroscope

Each gyroscope measured the angle along one axis of rotation. So, when GB-A is enabled, the current attitude of the spacecraft is fixed. There seem to be no functions for automatically entering attitude angles, so its likely really just prograde or retrograde or Igla...etc, but no complex 3D maneuvers. Those gyroscopes also only allowed a very limited range of error angles. Its really a big difference to Apollo or Gemini.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Alright, new one up:


New:
  • Orbital attitude hold
  • Added Vzor orientation functionality to KSU (still no periscope on the VC itself)
  • Added docking assembly (CM) jettison functionality tied to KSU
  • Fixed bug in Igla sequencing and introduced starting conditions from close range
  • Various mesh edits: New BO docking light (zenith) and RF shielding on BO and SA
  • Igla narrow beam antenna gimbals towards target on approach
  • Texture/material rework
  • Several ELS signals and BTSI DKD light added
  • Inertial attitude hold (integrating BDUS)

For now inertial just requires the BDUS on from column I. If I'm reasonably certain on inputs, I'll eventually differentiate gyro and integrating BDUS, but code-wise I'm going with the integrate angular rates approach either way, since Orbiter already gives me rates and timestep length directly.

Each gyroscope measured the angle along one axis of rotation. So, when GB-A is enabled, the current attitude of the spacecraft is fixed. There seem to be no functions for automatically entering attitude angles, so its likely really just prograde or retrograde or Igla...etc, but no complex 3D maneuvers.

Is it possible for a third axis (pitch in this case) to be measured by a combination of both free gyros? Found a reference to it online, though the context was CMGs. It does seem to indicate only roll and yaw are measured, but this bit about the gyro system confused me:
1652289582154.png

Unless it's cheating with the BDUS, it would have to have a way of knowing if the 8º in pitch have been reached.
As for the prograde/retrograde hold, it seems to either use the infrared sensor + yaw rate integration, or the integrating BDUS on all axes to hold attitude.

Not sure about the maneuver capability, the ASTP report says:
1652288353729.png

I'd imagine it to be something like: input desired roll and yaw angles, start in the (0, 0 ,0) inertial orientation after uncaging, roll x degrees, then yaw y degrees, to reach some predetermined attitude. That -OK and -T seem to only allow alphaX and alphaY input (from BTSI photos) might mean there was no manoeuvring with the integrating BDUS, at least through manual input.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,845
Reaction score
2,581
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
You should also take in account the other sensors, especially the sun and the ion flow sensors.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
You should also take in account the other sensors, especially the sun and the ion flow sensors.
Yep, already have those in. I have Orbital orientation hold taking advantage of those outputs.
Maybe the solar "azimuth" and "elevation" angle inputs would be attitude change relative to the fixed solar orientation, just as x and y would be relative to inertial.


Can't speak about the internals since I don't know much about the Soyuz, but I found the model really pretty and realistic! Great exterior (y)
Agreed! Concerning the exterior, credit goes to castorp/OctoberSky's original meshes, which I've only tweaked and built on with minor things, but they still held up very well some 15 years later.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,845
Reaction score
2,581
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
As I see it, the system works by first aligning the spacecraft to sun and ion flow and then use the to attitude gyroscopes for rotating the spacecraft off the reference. For that 2 rotations are enough.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi "diogom"

very nice work, I will download your new version and run some tests....highly appreciated your efforts.

don't know if you know, or you are interested to know, but recently I spent some time to understand how to use flight gear and the space shuttle of Thorsten, and i saw in the flight gear spaceflight forum that some few years back a Russian engineer working at the Gagarin cosmonauts training center wanted to reproduce the Soyuz new model (but he didn't go too far it seems); but at least he was so kind to put available on internet some operational manuals of the cockpit and systems of the new generation Soyuz and he was keen to help but apparently the project didn't materialize .... maybe he is still available to “talk / discuss “ ?????
I know it is not useful for your own project, but I was just wondering if you were aware of it or not, as finding English documentation around about Russian spacecraft’s and a real man working with Soyuz it is not easy , as Urvumpe was so nice to "direct me" to find some English Soyuz documentations time ago.....

i can't attached the zip file, as too big (I got a message when trying to do it....) but you can get it going to the flight gear spaceflight forum and looking for the the post with title "Soyuz-MS for flight gear" .... somewhere there you get the link to the doc file, (see photo).
if this link works it should send you there....but not sure, it is my first time I try to attach a link so don't know if i did correctly (sorry for that and my poor forum abilities :cry: )
FlightGear forum • View topic - Soyuz-MS for FlightGear

Last question to you:

I saw back in your posts that you and Urwumpe were talking about a “Soyuz book …. “ with technical data ….
Can you please tell me the title and author to google it?
I would be interested to get one copy of it if available for purchasing somewhere…..(if you think it is "worth of it")

Thanks again for your efforts….and good luck.

PS: please forgive me if I broken some orbiter forum rules --- -i don't know if I am / was allowed to make reference to others forums, if so please my apologizes.....
 

Attachments

  • post to soyuz file.JPG
    post to soyuz file.JPG
    15 KB · Views: 5

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
I saw back in your posts that you and Urwumpe were talking about a “Soyuz book …. “ with technical data ….
Can you please tell me the title and author to google it?
I would be interested to get one copy of it if available for purchasing somewhere…..(if you think it is "worth of it")

Hi thermocalc, thanks for the tip! I'll have a look, any information is welcome. Soyuz did indeed change a lot since, but honestly the Soyuz-TM manual from earlier was pretty useful, since some systems remained, or if anything, it clarifies on some acronyms and terms. Even if the technology evolved, there is still the russian way of designing the ship and controls. Might be worth getting in touch, though not sure anyone alive at Roscosmos remembers the old ships :unsure:

As for the book, it's "Soyuz - A Universal Spacecraft", by Hall and Shayler. It's not too crazy in depth, and since it's a bit niche it's on the pricey end for a paperback, but probably the most complete book about Soyuz you can find anyway. It's mostly historic, with some ship and procedures description.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Figured the docking system is due for some attention, so that will probably be the next focus.

As far as the mesh goes, the SSVP is currently too big I think. The "tunnel" diameter is mostly there, but it needs to be recessed into the BO a bit. The actual rod, head and alignment cone (latter is missing) need scaling down, and hopefully I can put some more detail on the head (latches) and ring (hooks, for example). For the most part, it seems the design was mostly the same as the current Soyuz, so references shouldn't be too hard to find. According to Russian Space Web, the alignment cone "skirt" thingy was added post Soyuz-10 as reinforcement.

For reference, Progress-1:
1652576971546.png

And Soyuz-26, which seems to confirm the skirt thingy, if the resolution can be trusted:
1652577874611.png

On the systems side, based on the 7k-TM's APAS analogs and the later Soyuz-TM, there likely would have been commands for rod extension/retraction, latch extension/retraction and hooks opening/closing. Latches on the head create the first mechanical link by trapping it on the station's docking cone, hooks close and retract into the docking ring to create the airtight seal and second mechanical link.
Big question is if even back then, the latches would extend automatically after rod extension, and if the rod retraction and hooks closing would also be automatic after docking (I'd imagine one "master" command would still have to be given, even if remotely), or if each of these steps would have been input manually (this option was there, in any case).

Regardless, planning on having each of these steps working, at least at the logical level with the corresponding panel inputs/outputs. Not much to simulate with hooks on the physical level, other than a retraction animation you'd barely see anyway. The current soft-dock/hard-dock animation and logic will need adjusting, of course.

Might also look into making this thing less forgiving, as in only being able to dock if the rod and latches are extended for example. There's potential here for future failure simulations.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,384
Reaction score
429
Points
98
Phase 1 complete:

1652669067025.png

And I only managed to ruin three animations. As usual, normals were by far the worst part, but I think I found the trick: export to Orbiter, re-import to Blender (now in triangles), and only then do the normals.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
6,095
Reaction score
3,179
Points
188
Website
github.com
As usual, normals were by far the worst part, but I think I found the trick: export to Orbiter, re-import to Blender (now in triangles), and only then do the normals.
Shipedit.exe can also calculate normals.
 
Top