Project Soyuz 7K-T Custom

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
So after some further research (mainly TMA SUS training manual), turns out that as early as Soyuz-TM there is in fact active control during re-entry. It checks against a pre-programmed (one of several) "lost velocity / time" curve every 200 m/s, and adjusts the angle depending on if it's reached that speed too soon or late. In fact, it overcorrects to compensate the period when it was too shallow/steep.

Big question is, how much of this capability would 7k have already. Far as I can tell, there's no instrumentation output to the crew on the trajectory, nor the control inputs that later Soyuz has, so I would say the options are either "regular SUS" or ballistic, no manual mode. As for the normal re-entry, I think I identified the manual input to pick which way it would roll at the start of re-entry (left/right), which of course affects the lateral trajectory. Other than that, don't really see any of the versatility in speed/time curves modern Soyuzes have, especially since it relies on digital computers introduced after 7k. I could see though 7k having one single "hardwired" re-entry profile, generating analog signals proportional to the difference from the expected curve to feed into the roll channel. @Urwumpe did you ever find any specific info on early SUS?

There is of course the fact I wouldn't have said curve to implement anyway, but I think I could at least approximate one from TMA and hope it's good enough.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Nothing more specific than you should have. Yes, very likely hardwired analog logic, possibly based on an integrating accelerometers. There is also no way for the crew to change the landing site or to review the coordinates that the guidance uses (beyond a fixed lead angle in the globe instrument), so its likely only a "semiguided" reentry in the sense, that it limits the maximum amount of lateral velocity from the initial ground track by the output signal of an other integrating acceleration sensor, that is preloaded with the velocity change expected during reentry (inertial EI velocity - inertial velocity at end of guidance). Which means: The slower the Soyuz capsule gets, the less difference from the original groundtrack is allowed. I doubt that the early Soyuz already had the guidance packages installed, that allowed a skip reentry at lunar speeds with a guided landing in the USSR. This was expected to use a more sophisticated computer.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
Hm, so "worry" more about keeping it in a certain horizontal corridor, and the vertical path is what it is? Though in that case the solution is to hold roll at 0 degrees always. I guess IRL there might be some perturbations, but as far as Orbiter goes it's quite stable. Or still have some control of vertical speed, if anything just an initial estimation for roll at entry interface, but minimize the horizontal drift, maybe with a roll reversal at some preset velocity?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Hm, so "worry" more about keeping it in a certain horizontal corridor, and the vertical path is what it is? Though in that case the solution is to hold roll at 0 degrees always. I guess IRL there might be some perturbations, but as far as Orbiter goes it's quite stable. Or still have some control of vertical speed, if anything just an initial estimation for roll at entry interface, but minimize the horizontal drift, maybe with a roll reversal at some preset velocity?

Well, no, the plan was to use a gliding reentry, so its similar to Gemini, Apollo or the Space Shuttle. But likely much less sophisticated as for Gemini:

By rolling the spacecraft, you indirectly control the descent rate and by controlling the descent rate, you can control the deceleration (g-load) on the crew. But if you would always bank to the same side, you would fly a curve away from your ground track. So, you need to do roll reversals. This could be triggered depending on your flight path, high altitude winds and the target coordinates.... or much simpler for simple Cosmonants: By the ratio between lateral velocity and current velocity. If accumulated lateral velocity exceeds a certain (small) threshold, you need to reverse, the lower your speed is, the smaller the threshold has to be. A too low threshold would be sickening, as the spacecraft would be wildly rolling around without actually being able to steer itself. So you need to start at a high threshold velocity and gradually reduce it to stay close to your intended corridor. At the end of the reentry, you want to null it completely and go either into a steep dive or into a full lift configuration.

I think for Apollo, they went into a controlled dive at the end of reentry, but I am not sure about Soyuz there.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
magazine article describing atmospheric reentry (1980 should refer to Soyuz-7K)

May I rant a little? Why in Blakes name are Russian technical reports so unstructured?! This one almost reads like what we call a "media kit" for journalists in the west.

The article describes a bit of things and the key subsystems of all spacecraft involved in the Salyut program, but quickly jumps from topic to topic, without any main thread or storyline.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
magazine article describing atmospheric reentry (1980 should refer to Soyuz-7K)

Interesting stuff in there, thanks. The detail of the 10000 km of separation after launch, for example. A lot more detail on Salyut itself than I expected, actually. And it seems the SA's thrusters are actually 5 kgf higher than what I'm using.

May I rant a little? Why in Blakes name are Russian technical reports so unstructured?! This one almost reads like what we call a "media kit" for journalists in the west.

The article describes a bit of things and the key subsystems of all spacecraft involved in the Salyut program, but quickly jumps from topic to topic, without any main thread or storyline.

Rant away, it is a bit chaotic.

Alright, Gemini makes sense, and I agree it would probably look similar on Soyuz (thanks so far btw). I reckon I can work up a "lateral velocity accumulator" if I think about it long enough. On this aspect, TMA and co. seem to do only one roll reversal per entry, which is why I'm wondering if the earlier models already did that, or there were indeed several reversals as needed and something in the modernisation made only one enough. The former way would probably more accurate, the latter seems to be described as "close enough". Either way, the ratio of lateral / longitudinal sounds like a good idea.

As for vertical guidance, from my quick read up Gemini seems like it was a step above Soyuz, with the "fancy" inertial guidance. That is, from all I've heard so far it doesn't seem that Soyuz knew where it was landing and thus where to aim with lift, as you say too, it was just given a time to retro-burn and followed the program: orient, inertial hold and burn, separate at 140 km, SUS on, etc. Unless there's something that can be uploaded to the ship from the ground (but not by the cosmonauts?). In fact even TMA and co. don't seem to be that sentient, they just determine and feed it the most appropriate speed/time curve to follow to reach the landing site, and it "blindly" follows the curve.

The solution I'm seeing with all the input so far, as far as implementation, is a fixed "speed change / time" curve. So start counting when re-entry starts, have integrating accelerometers measuring both lost speed and lateral motion (drag and something else), and periodically (or continuously?) check if more or less lift is needed, and roll accordingly. When the lateral / longitudinal threshold is reached, roll reversal. This would be a curve I'd estimate from one of the TMA ones, knowing the overall shape and using 7200 m/s as the end of reentry, not the first time I'd fire up Matlab and MacGyver some curve fitting 'till it's good enough. As for the end portion, the way of TMA as I understand it is at 7200 m/s, reentry is considered done, it holds the current roll angle and at a certain altitude, engages the ballistic mode until the parachutes are deployed.

Sounds realistic? Still not sure if I'm complicating too much or not.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
Since it's the low hanging fruit, had a start on Ballistic:


Had to change the roll thrusters: previously they were purely roll (Orbiter Z axis), and during ballistic reentry that just meant that lift always remained positive, even on 180º roll. The "roll" should instead be around the velocity vector (opposite of red Drag in the video) while in a balanced orientation during reentry, not the capsule's own longitudinal axis. In theory I think the capsule should rebalance itself just from aero loads, but I don't know how rotation would factor into it.

So I noticed from pics the roll thrusters on the SA aren't actually parallel to the bottom edge, they're somewhat angled "inward" towards the hatch, as they are on the mesh as well: this I'm assuming fits like a glove into their thrust vector being orthogonal to the velocity vector. From photos it seems certain to me they're at an angle, I just haven't found confirmation that that's the purpose. But I angled them around 20º in, and from the capsule's point of view, roll is no longer purely roll, but it works out during reentry to keep the angle of attack and balanced position more or less constant.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
During reentry, you also use the pitch and yaw thrusters to stabilize the spacecraft near the desired AOA (with a relatively large deadband). Not sure if Soyuz was able to do that during ballistic reentry, I assume not. Apollo and Gemini did that, but both also degraded to a pure rotating ballistic reentry, once they had no reliable data about the orientation of the spacecraft.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
During reentry, you also use the pitch and yaw thrusters to stabilize the spacecraft near the desired AOA (with a relatively large deadband). Not sure if Soyuz was able to do that during ballistic reentry, I assume not. Apollo and Gemini did that, but both also degraded to a pure rotating ballistic reentry, once they had no reliable data about the orientation of the spacecraft.
Supposedly, for TMA at least, the limits to get into ballistic are 173º in roll and 54º in yaw. Though interestingly the gyro suspensions seem to be aligned to the velocity vector in the balanced position, not the body axes. Same deal for the descent BDUS, seems like I have some realigning to do, can't fully reuse the existing code for the orbital portion. As for pitch and yaw during ballistic, the back-up ballistic section mentions pitch and yaw being damped, though as I understand it the threshold is 3.5 deg/s (in that mode, with a dedicated BDUS set, possibly lower in regular ballistic). Edit: had the realisation that the yaw thrusters are conveniently placed and oriented to give "perfect" yaw (no unintended pitch or roll rates) in this velocity vector coordinate system. While measuring yaw relative to the body axes, every way I think of it they will always introduce some roll and sometimes pitch. So one more thing to adjust, and it seems like the whole thruster system was designed around that 20º rotated coordinate system for reentry.

For interest's sake:
1660074602358.png
Gamma is roll and Psi is yaw, relative to velocity axes, x and z are switched relative to Orbiter's coordinate system.

Meanwhile, took some time to update the main chute:
1660075434513.png

Normals pending. Still working out how I'm gonna do the pilot (I understand there are two in quick succession?) + drogue sequence, in terms of which objects are created and animated, but drogue at least is gonna be a must for this release.
 
Last edited:

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
As far as re-entry guidance for the ballistic mode, I'd say that's pretty much complete. Behaviour is looking good and stable, also added in the respective indicator lights and for any descent, the venting of all propellant when the heatshield jettisons.

I do need to have a look at the aerodynamics. I had to reduce the rotation drags, since at "max-q" the roll thrusters were having trouble keeping up the roll rate. Modern Soyuz has an extra set of roll thrusters precisely for this reason, so maybe I overcorrected, though I haven't been able to confirm their presence in 7K yet, there's some contradiction. For example, Soyuz 10:
1660860696801.png

And Soyuz 30:
1660860738401.png

Also, as far as documentation of the real thing goes, the (passive) stabilisation in pitch should be finished at around 95 km, yet it's still going (slow and wide swings) at entry interface in Orbiter, so I'm having to manually kill rotation at the correct pitch. Also, the entry interface defined as losing 25.6 m/s in speed is happening around 72 km, while it should be around 80 km. Could either be a thinner atmosphere or lower vessel drag than expected.

One other factor is the centre of mass should be offset 85 mm vertically, but the centre of pressure still on the symmetry axis, but when I tried that, nothing I changed could get the balance point at 20-25º AoA, it was more like 35º, sounds a bit too much to settle for. Currently it's shifted 0.5 mm, maybe the much smaller difference between centre of mass and centre of pressure could slow down the process of reaching the balance position? It did stabilise quicker when I had 85 mm. Maybe I missed something in the vessel configuration which could make that offset work.

I'm wondering how much this is my cross sections / drags / CG, but also Orbiter's atmosphere having some differences from reality. I'm using the values from Shipedit (3.8 m^2 cross-sections, give or take, seems about right for the heatshield side at least), but while the L/D is correct (0.3) throughout entry, I don't really know what drag values to expect realistically. Same goes for the airfoils, not sure what chord length and wing area would be for a capsule.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi diogom,
i was just wondering if you released a new version after this file "7k_T_dll_13062022" or if it is still the latest ?
thanks.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
Hi diogom,
i was just wondering if you released a new version after this file "7k_T_dll_13062022" or if it is still the latest ?
thanks.
Nope, that's the latest. Still a couple of things to wrap up for the next one, but it's on hold for the next few weeks.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
Just as an update, easing back into this now. But I'm doing a relatively deep dive into the whole airfoil thing and trying to find some existing models/numbers for the capsule (found a chinese paper on the effects of ablation to start with, which has some CFD figures). The current lift coefficients don't look too bad, but everything else I'm not too sure about. And I need to figure out how to get the trim angle near enough to the magic 22º with a realistic CoM offset. I know I shouldn't expect everything physics to be 1:1, but achieving this now with 0.5mm compared to the documented 85mm doesn't sit right with me, especially with it taking much longer to stabilise at the trim angle of attack.

I guess there's enough new stuff besides re-entry since the last version to warrant a new one, but I'd really prefer to wait a bit longer and have this already included. If this ends up taking too long, I'll release it with the current aero and ballistic entry, which is already an improvement. No need to rush features but I don't want to take half a year between releases because of one blocking issue.

On a semi-related note, I've been including the C++ sources all along anyway, but starting with the next one I'm going with MIT for the code. Seemed like the most appropriate from what I've gathered. As for the meshes and textures I'll leave as is since at this point it's a mix of mine and castorp's work, that's probably a grey area with licensing (if MIT even is appropriate for non-code assets).
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
So for future reference, and maybe this is already well known, but I had to try it, making the airfoil symmetric (in terms of pitch moment) about 0º AOA (or in this case +-180º) and having a centre of mass / centre of pressure offset ain't gonna work I think. As I understand it, remaining option then is to force the ~20º AOA with the moment coefficients. So the difference to what I was doing before is have no CoM shift at all and have "stronger" moment coefficients.

For reference, using the data from this:

Might not be exactly right, and of course it assumes Mach 5 at 40 km, but at least I get in the ballpark. The moment coefficients alone are 10 times larger than what I had before.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
New version here:

Now that there's a proper place for addons, all releases will go there, no more flimsy Google Drive links. Changes:

Kavkaz - 18/10/2022:
  • Igla reworked for far-range approach and typical mission profile
  • Descent Guidance: basic SUS control, ballistic reentry, SA thruster and aerodynamics rework
  • New main parachute mesh and texture
  • Drogue chute added
  • Interior lighting adjustment
  • Aft beacons position changed according to 7K-TM
  • Minor PAO mesh adjustments
  • Vzor model and optical functionality added
  • Gyro or DUS for inertial added (BDUS integration)
  • BDUS now required ON for any angular rates in orbit
  • Integrating Accelerometer for (manual) SKDU burns added
  • Switch from Igla to Igla-monitored manual approach added
  • Thermal covers animation on PAO separation
  • Documentation updated / Flight Guide added
  • Code now under MIT license

Unsure where to head next. Open to suggestions. Thinking basic battery management is due, now that the flight profile is solidifying, but the automatic flight programs (orbit correction, de-orbit) are also looking appealing.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
hi diogon,
nice to see your new release and your outstanding steady progresses, thank also for the flight notes/tutorial like document, it was really a nice surprise, especially now that the spacecraft is getting more complex to operate realistically.
hope you carry on with the good work in bringing to life more systems, about suggestions ... in my modest opinion, I think now that you have almost figure out most of the G&N staff, it would be good to keep going in implementing the rest of the G&N staff/systems (like the programs and bringing to life the Program Indicator ICP to monitor them), so that once the G&N is done, you may further concentrate your efforts in the internal systems implementation, and maybe before bringing to life the KEI and the systems, i guess the electric system should happen first as you were already alluding to :hailprobe:
anyway, thanks again for your efforts and whatever next direction you will take, tackle first, it will surely be a good move for the continuation of this project.
take care and good luck, stay safe (just recovered by covid 19, still weak and short of breath but still alive :cheers:....).
 

Gargantua2024

The Desktop Orbinaut
Joined
Oct 14, 2016
Messages
1,050
Reaction score
1,257
Points
128
Location
San Jose Del Monte, Bulacan
Unsure where to head next. Open to suggestions. Thinking basic battery management is due, now that the flight profile is solidifying, but the automatic flight programs (orbit correction, de-orbit) are also looking appealing.
Since the 7K-T variant is the only Soyuz that operates entirely on chemical batteries, the crew should make their rendezvous and docking to their target Salyut station no longer than 2 days. Failing to do so (like in flights 15, 23, 25 and 33) will result in an emergency landing back to Kazakhstan. This would be quite an interesting challenge to Orbiter as well especially that modern Soyuz flights now take only six hours to make its rendezvous to the ISS
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,370
Reaction score
413
Points
98
Some first thoughts and findings: As best as I can tell, they probably would have used silver-zinc batteries (Chertok on 7K-OK / LOK). Not sure if I can approximate a "voltage over time" from that and 27 VDC of onboard power alone. From the power indicator at least I know it wouldn't be higher than 40 V normally. Documentation (Tyapchenko) also only mentions error percentages for the 20-40 range, maybe 20 was the expected lowest? And regulators trim/boost it to 27 V within that range, of course. And this is all based on buffer batteries for the solar panelled ones, which probably would have been different enough in capacity.
Speaking of capacity, of which I have zero solid info on. Astronautix claims 0.84 kW average with no clear source (lots of paywalled Aviation Weekly or links lost in time like tears in rain), which would lead to ~40 kWh for 48 hours. But then also claim 18 kWh and 0.5 kW average for the PAO (with no source), which leads to 36 hours, so a day and a half of flight. Also from Chertok, the backup battery should be good for 3 orbits (~4.5 h), so 40.5 h, it's not far from two days in total, but still maybe a bit on the low side. This is all relative anyway, the first uncrewed ferry lived for 6 days since it could turn off certain systems.

Sooo.... gonna have to make up my own figures, won't I. Unless there's something well hidden out there to be found. Then again I never expected anywhere near NASSP-tier details on this, I could live with the 0.84 / 48 h approximation and a voltage estimation just to see some needles move.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
dear "diogon" ... highly appreciated all your efforts and technicalities, but as you mentioned high fidelity addons with little real documentation to get inspiration from are very rear, especially for free, so your project is going to be tough for sure, but "Rome has not been built in one day" :cool:, so don't lose momentum :coffee::coffee::coffee:, and if sometime you stumble upon "unknown" , to move on you may need to do some approximation/take some shortcuts, and here your "gained ability and astronautical feeling, know-how kicks in" :unsure:, letting you decide the best "values" for some unknown variables; until when more information will be available to correct them, so even if at the end your Soyuz will not perform 100% as the real one was, it will be ok for the time being :p....if in the meantime you manage to get the real numbers you may always fix backward (y); if not, you move on (n).... as there are many more Soyuz out there to reproduce/model :coffee::coffee::coffee::coffee::coffee:... so hope to see many Soyuz modelled within the next decade for Orbiter... as you are the mastermind behind all of this, and you do for passion, of course you will do whatever you like and feel happy to do, so in a nutshell: "Soyuz-7K: a small step for "diogon", a giant leap for "orbiter community" .... :hailprobe:
 
Top