Project Soyuz 7K-T Custom

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
1.3
I downloaded 1.2 too, just for the case.... but wasn't thinking about it too much I guess
cause I always prefer to have latest versions of mods
should I go with 1.2 ?
Yep, igel confirmed that 1.3 has a bug and doesn't work with 3rd party payloads. 1.2 should work fine for launch.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Did a new thing:

Orbiter 2016 [D3D9Client] 17_06_2022 19_20_02.png

Needed to rejig the panel a bit, but physically the periscope is ready I think, some more detailing later on aside. It seems there were some small aesthetic (and functional I bet) variations over the years, mainly on the top cover, but as usual decent 7K references are few and far between, so I based it on the Soyuz-TM look, oldest I could find. Far as I can tell, the cover design changed either during TM or with TMA.

Big step now is figuring out how to use the custom cameras thing to make this work. Had a quick look around the forum and the API guide, but haven't put much effort into it yet. There's a central "screen" object and eight peripheral objects ready in expectation of it being similar to the usual VC blitting process.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Oficially started work on the Vzor. Let's see if I can navigate the D3D9 seas. As far as I can tell what I'll be using is already outdated (gcAPI), but oh well. At least I'm under the impression that's the only option for base O2016 and R25.
Already stumbled into the apparently age-old barrier of Character Set to "Not Set".
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Error by error, finally managed to create a Sketchpad2, the rendering surfaces and the two custom cameras for the central screen. At least I think so.
Now to crawl through whatever isn't working with the actual update part.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
So, here's the funny part:

1656038244107.png

I gave up on using Sketchpad2 after running into a CTD "assert fail" wall, and defaulted to the same method used to update the rest of the panels, blitting straight from the cameras' render surface. Does anyone know if there's some significant performance impact that makes continuing to pursue Sketchpad worth it? As far as I understood what I read so far it ends up blitting anyway, but might be done differently. Performance is good for me but I don't exactly have a modest machine.

Question now is how to get the 8 peripherals + central screens without potentially destroying the refresh rate, since just having two cameras already has a noticeable impact.
Each peripheral view would I believe be 30º FOV looking mostly radially, so not sure there's a way to escape 8 individual cameras.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,882
Reaction score
1,538
Points
203
Location
Langendernbach
You could create one camera pointing downward, give it 180° field of view, and cut the central 120° away by choosing different texture coordinates for each viewport.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
You could create one camera pointing downward, give it 180° field of view, and cut the central 120° away by choosing different texture coordinates for each viewport.
Ok cool, so they can go well past 90º. Yeah, that might be the best bet.

Good old Soyuz 4/5 video has some Vzor in it:
1656079919928.png
I get the impression the viewports were "inverted" to what I expected, as in when looking straight down at Earth, the inner half would be space, outer half the Earth. But this could be the central screen looking forward, not nadir, and thus be a bit misleading.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,882
Reaction score
1,538
Points
203
Location
Langendernbach
I get the impression the viewports were "inverted" to what I expected, as in when looking straight down at Earth, the inner half would be space, outer half the Earth. But this could be the central screen looking forward, not nadir, and thus be a bit misleading.

As I understand it, those viewports simply show the horizon around the periscope in such a way that Earth should be inside the vzor and space on the outside. So, when you are level, all views show the same amount of earth.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
1656093269063.png

Different screengrab, looking almost directly at the horizon. Yeah, Earth on the inside makes sense, this seems to agree too, it just confused me without much context. If the central view here were looking down towards nadir, I'd expect the peripheral screens on the right (right here is in the longitudinal BO direction) to mostly show the Earth. Assuming it is looking forwards, in the "docking" orientation, then the vzor is pointing mostly perpendicular to the Earth and away from it, hence the peripherals only showing a bit of horizon, and Earth "on top". Rotating this around in my head, Earth on the inner halves when aligned works.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Alright, best I can do with one camera I think:
1656107491502.png

Ended up at 154º FOV (77º for each "half"), could fine tune one way or the other. Things get really weird as it approaches 180º.
Ideally it would be the 8 camera approach, that would probably look better overall with less angular distortion and a smaller FOV on each screen. But it just doesn't seem viable with the current refresh rates. No point in looking "perfect" if it also runs like a slideshow (it already kinda does with two active cameras, which doesn't bode well for the eventual TV docking camera for the KEI display. Assuming resolution of the cameras doesn't impact it, which is currently at 1024x1024 for both).

One particularity here is the Vzor is physically angled 6º off the y axis, and the sim-Vzor reflects that, pun unintended, so the orbital orientation that the "SOUD" establishes automatically with the Ion and IR sensors won't quite look like the above, which would be the manually established case.

As far as the controls go, for now I might just do the shutters (Шторка) on the peripheral screens, not sure how those look like physically. The other controls are optical filters and central screen focus. Need to fix a bug where if the vzor direction is changed while in the VC, it won't automatically start rendering the new view without exiting and reentering the VC.
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
188
Reaction score
64
Points
28
Location
Bangkok
nice, steady and regular timed improvements to your "creature" from your side, you are a GREAT man "diogom". :hailprobe:
take care and all the best.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
New Anatoly Zak dropped on the first 7K-T with a fresh render: http://russianspaceweb.com/soyuz-7kt-kosmos496.html

Good to see some matching details on the exterior. Of note though is the missing shield on the BO, which is definitely there on the Salyut 6 pic and had already been a usual feature of 7K-OK. In the meantime I also noticed the PAO light beacons were offset on ASTP (that is, not in line with the x=0 plane). I've corrected this but it's a gamble as to whether 7K-T would also have them offset, or even have them at all. Best reason I can think of for it is to move the beacon a bit further away from the sun sensor, on the "top" side.

Been focusing a bit more on overall research and planning things out. Considering an Igla upgrade next, which would involve a smarter control of lateral drift. The only reason I limit it to 5 km max is the DPO can't keep up with burning off the lateral drift on approach from larger distances, and to be honest, even if it could, I don't think there would be enough fuel for control up to contact. But as I understand it, at a certain point in the approach, Igla would orient the Soyuz 90º relative to Salyut, in the opposite direction of the drift vector (so called motion of the line of sight) and use the main engine to burn that off. Interestingly, that information came from the antenna's Cardan suspension, which auto-tracked the passive ship's beam and fed the current angle and angular rate to the Soyuz """computer""".
1656617819370.png
So I'm thinking with the data I'm already collecting, I might be able to calculate this motion of line of sight direction and magnitude, and orient Soyuz to burn it off with the mains. Since drift will continue to build up afterwards, maybe even overcorrect a bit? This way, Igla could be turned on from, say, 15-20 km away, the mutual orientation established, if the approach speed is excessive it can be burned off with a "retrograde" burn as normal, and vice versa (instead of currently having to first station keep at 5 km and then engage Igla, which is kinda the same thing but fuel is wasted in actually stopping). It would then coast until a closer distance, with the drift kept in check by the main engine, and once close enough do the existing sequence using DPO. There's a balance to this though, I'm sure, because one might end up using too much SKDU propellant, and have none for the de-orbit burn. On the other hand, too much pitching and yawing around using DPO and it's toast, so either use DO and take the time hit or be quite strict with the amount of rotations.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Interesting, it appears after some change, the stock DX7 client now has interior lights:
1656713921952.png

Unfortunately it kinda looks like crap, though at least visible, but the frame rate is miserable (in VC only). I made some changes to the interior lighting (colour, to better match the supposed ~4000K temp, and higher attenuation to make it more uniform) but that wasn't it after a quick rollback. All Vzor functionality/resources are gated with gcEnabled (otherwise the VC won't even load), so shouldn't be that either, supposedly. All else I've done is mesh edits and add the accelerometer, which is just another display+knob and some GetForceVector code.

Guess it's partly on me for not AB-ing every single change on DX7 too. I've tried to keep things compatible in both as much as possible and for the most part it's just taking the time to convert the textures with DxTex after editing, but to be honest, I see the stock client as a dead end.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Rambly post ahead, consolidating thoughts but also open to ideas:
To start with, currently I have the RCS ISP at 117 s. I got that value I believe from astronautix, but that doesn't refer to the Soyuz itself, it's a loose value. All I know is it's highly concentrated hydrogen peroxide monopropellant, and I've seen max theoretical ISP for H2O2 ranging from 160 s to 200 s, so not sure what a realistic figure would be for the Soyuz RCS, knowing the actual thrusters aren't 100% efficient. Also assuming the stuff that's on Soyuz these days performs a bit better (in thrust they certainly do). But could it really be as low as 117 seconds? Needless to say it would relieve things a bit, the more the merrier, but if it really was that low, then so be it.

So the best source I have on an actual Igla sequencing is Chertok's account of the Soyuz-10 approach. While an amusing read due to the constant absurd micromanaging from Mishin and co., I'm finding it a bit confusing to make sense of the sequence. Partly due to extracting passage of time from text, I'm sure, the dual reporting by telemetry and crew, also curious how he's able to give such precise recollections (aka is there recorded audio somewhere). This isn't necessarily a "I must code it to behave exactly like this" to the point of it being impossible, more just trying to understand the supposed sequence, and hopefully not overthinking it.

Here's what I get out of it in order. Relevant info starts on page 324 of Rockets and People Vol. 4, the public NASA PDF:
  • Weird inconsistency with the first range measure given as 10-11 km, and later on being 15 km, after Igla lock on. Top brass has a meltdown over this, but no explanation given. Maybe 10 km was the closest approach and there was some drifting away before it had time to properly burn and start closing in;​
  • DPO burn for over 45 seconds (how much of the tank evaporated just from that?), followed by a call-out of 8 m/s range rate;​
  • The next call-out from the crew is range 15 km and rate 24 m/s. Sounds reasonable;​
  • At 6 km, rate 27 m/s, first mention of a DPO-powered flip to point the engine at Salyut (DOS) and brake;​
  • After the burn indication, given range and rate are 4 km, 11 m/s (basis for the initial approach speed the current addon version uses starting from ~5 km);​
  • Immediately after this, it's said DPO is turning the ship again. This is where the mess starts for me [1];​
  • 3.5 km, 10 m/s, engine fires again for 33 seconds and rate is down to 8 m/s at 2.7 km;​
  • Around 1.6 km, 8 m/s, another turn starts. Engine fires 7 seconds;​
  • Down to 4 m/s at 1.2 km;​
  • Down to 2 m/s at 950 m, engine fires again for 5 seconds, turn reported;​
  • Last crew report and telemetry as they leave radio coverage is another engine burn, rate increases to 4 m/s at 800 m. Ground mentions just 13 m/s delta-v reserves on the main engine (the amount that still makes de-orbit possible), and 20 kg DPO left. Docking happens within 30 minutes.​
[1] So at 6 km I feel confident in saying Soyuz is pointing away from Salyut (let's call it retrograde), burning off the 27 m/s down to 11 by 4 km.
Then another turn starts, and another engine burn at or below 3.5 km seems to drop that down to 8 m/s by 2.7 km. Now, 500 m at 11 m/s, that's around 45 seconds of travel time. Assuming a (documented for manual mode) max turn rate of 3 deg/s, fuel guzzling aside, that's more than one minute for a 180 degree turn. Either way, it makes no sense it would flip 180 to point prograde and reduce speed with the main engine (physics says no), and it would also be a waste of fuel and bordering on impossible time-wise to flip prograde and immediately flip back retrograde again.
So I'm assuming this is one of those perpendicular/normal burns (b in post #95 of this thread) to reduce lateral drift. Soyuz turns 90 degrees from retrograde, and if they measure range rate (comes from RF Doppler) as a "vector sum" which includes lateral motion, makes sense to me range rate would decrease after such a burn. If range rate is just the longitudinal approach speed, not factoring in lateral stuff, not sure how that sits in my head. Either way, that is quite the long burn to burn off just 2 m/s.
If Soyuz held this perpendicular orientation (main dish gimbals and remains locked in line of sight with Salyut throughout the whole approach) until the next turn around 1.6 km, said turn should have been back to retrograde, as the speed is halved. Compare this 7 second burn for 4 m/s difference to the previous one. Further reduction to 2 m/s seems to be from the 5 s burn, followed by a turn. And then another 4 s engine burn and speed doubles? Rendering the previous burn useless? I know Igla wasn't exactly the smartest of things, but...
Anyway, crew ended up taking over manual control past 200 m, docked right down the middle, and the rest is history. Shatalov tells Chertok later he was kinda sick from all the turning and burning. Another note from this account is up until Soyuz-10, there was no control over individual SSVP actions: rod, latches and hooks opening/closing. All they had was "Dock" and "Undock" commands. This lines up with the 7K-OK KSU matrix, and also with 7K-TM's as they would have introduced more control to the cosmonauts after that being the reason they almost rendered Salyut 1 useless after one botched docking.

So what's my actual take away from this, if I have an accurate picture at all: a lot more main engine action than I anticipated, seems like it was in charge of lateral drift as close as 3ish km, and retrograde burns were a thing up to 1 km at least. My main concern here is the time it takes to turn, and the fuel it takes. If DPO isn't being used as much to null lateral drift, I guess that "extra" fuel could then be used on the higher number of turns. Also wondering if all the burns really were at "round" angles (0, 90, 180) or if it wouldn't be able to do something in between and kill two birds. On different points, the crew reported seeing the station on the periscope, which would imply pointing straight at it. In any other orientation, the vzor's field of view points away from the docking target.

For my implementation, I'm thinking:​
  • Initial approach speed at 15-20 km range is what it is, but maybe have a limit at 30 m/s where the Soyuz trims it down, and also a lower limit. Still, if the rendezvous is well setup, closest approach should be small enough;
  • The initial alignment for radio lock with Salyut should immediately detect the direction of the lateral drift. So, while pointing at Salyut, the magnitude of the relative velocity vector's x and y components. Here I'm assuming, before actual experimentation, that this direction will be approximately the same throughout the approach. This is important because the Soyuz would mainly pitch during the approach as the antenna gimbal had >180º range in pitch, but only 20º in yaw. So to keep the antenna in radio lock, only pitch can be used for the flip 'n' burns. If the first orientation towards Salyut rolls Soyuz such that the lateral drift direction is directly "up" (all y axis), then all it needs to do is pitch down 90º and use the main engine to start burning it off. Off the top of my head, since the approach should be from below and behind, this roll angle should be more or less aligned with the horizon, either way. Of course, relative inclination plays a part too. Maybe something like rolling until the (x velocity / y velocity) ratio is small enough works?;
  • Once initial approach speed is set, pitch to 90º and get rid of the lateral drift. Hold this attitude and burn as needed;
  • Around 6 km, flip to 180º and burn to around 11 m/s;
  • From there, do one more round of 90º pitch lateral correction, flip back to 180º to slow down further;
  • From 1 km down, point at Salyut and use DPO to control drift and approach speed down to contact.
This will still require some pencil and paper, but it's sounding doable if the fuel performance doesn't let me down. Still somewhat skeptical of doing this with a rendezvous to 350 km circular behind it, on 205 m/s launch Delta-V including de-orbit fuel.
Taking the opportunity to leave this here: http://www.svengrahn.pp.se/histind/ASAT/ASAT.htm#Abstract
 
Last edited:

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
Well, as expected everything turned out way more complicated than on paper. But after many iterations, касание! 20 km Igla range is now possible.

Igla activation: 19 km
~50 m/s SKDU used, from a potentially generous starting ~160 m/s
~41 kg DPO used, out of 87 kg initial (this is with the new 160 s ISP)
~6 kg DO used, DO consumption increases from aditional high-rate rolls during the approach
Three lateral SKD burns total. Lateral drift might be more agressive on more elliptical transfer orbits, since for this test scenario I approached Salyut from a relatively circular orbit. More fine-tuning and testing needed in different starting conditions, but happy with results so far.

1658339224955.png

1658339200293.png
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,250
Reaction score
195
Points
78
After some testing, I'm arriving at a "standard procedure". The more accurate scenario used: I used Transx to set up the approach, from a parking/phasing orbit of 250 km, up to Salyut's 350 km, ~30 m/s Delta-v transfer burn and a ~27 m/s approach speed (let's consider Transx's solutions to be Mission Control's beamed up burn instructions). The phasing time was around 6h, so I still probably need to work on Salyut's positioning at launch since rendezvous would supposedly happen on the second mission day. Interestingly, ended up with way more fuel in the tanks after docking, 129 m/s, plenty of margin for the de-orbit burn. Also just short of half a DPO tank left, so there might be some margin for decreasing the ISP a bit. Also validated the on-board accelerometer for now, which would be used to shut down the engine at the appropriate Delta-v. Eventually, it'll be essential for the engine burn programs.

So:
  • Closest approach should be set pretty close, ideally under 500 m, but higher is probably allowable. I reckon they would have been good enough at calculating a rendezvous, and some Salyut missions apparently engaged Igla as close as 4 km anyway. Practically speaking, Igla as I build it just can't handle say a 10 km closest approach, the fuel burn is outrageous and the drift increases too fast. Doable in a Delta-glider, in this hunk of junk, probably not, at least with the Igla philosophy;
  • Engage orbital orientation (prograde, horizon level) after the transfer burn, Igla on at 30 km (to clarify, I'm using Orbiter's built in distance measuring to gauge this). This needs some further studying because the initial orientation towards Salyut can be pretty slow, but if Salyut already happens to be mostly in front of Soyuz, then the proper approach sequence might start too early and end up with unnecessary fuel use.
That's it, Igla will do the rest hopefully. Keep your vomit bags in reach.

For the next release, I intend to both include some more scenarios at different stages of flight and update the existing ones, and also a Checklist of sorts. A guide to a full flight, basically.

As for the near future, after tying up some Igla loose ends, I think it's time to give re-entry and landing some attention. For re-entry: a pass at a re-entry autopilot, ballistic re-entry; For landing: new chute texture/model, include the drogues, refine thrusters, masses and aerodynamics to come to more realistic vertical speeds.

The re-entry guidance seems to have been relatively simple: the trajectory was judged from how long after separation it took to accumulate 25 m/s in atmospheric drag. If it's bang on, roll to and maintain 60º. If it takes too long, the trajectory is too shallow, and the roll angle is higher for less lift. If it's too fast, it's too steep and the angle is lower for more lift. The angle doesn't change throughout re-entry from that initial value, it's held until shortly before the chutes start coming out. As far as I can tell, this is still the method as recently as TMA. Ballistic, of course, is a constant roll in one direction to have zero net lift over one turn, and will either be automatically selected in some conditions, or selected manually. It also seems like there are preset Delta-Vs for the de-orbit burn, depending on the orbital altitude, as seen in the Soyuz-TM manual.


TL;DR: Igla should be mostly ready for the expected mission profile, needs some house cleaning then time to move to re-entry and landing overhaul. Checklist/Flight Guide in the works, new scenarios to be included.
 
Top