Hey, thanks for the data. Most of that is debug information basically, but I'm glad I left it in. I'll have a look later on, compare to what I see.
I don't have much of a bearing on whether the Igla code is an overcomplicated mess or not, but I approached it as a sequence of several different states, each does it's own thing, and the code cycles through them as needed. These are on the upper left as "Igla x":
- 1 is the initial rough orientation in pitch and yaw towards Salyut, it only runs once;
- 2 you can't really see, because all it does is tell Salyut to start it's own Igla, and it's also a decision point based on the initial distance and speed;
- 3 is the DPO translation correction. It's meant for the final phase, to keep Soyuz from drifting off to the sides;
- 4 is the fine orientation in pitch and yaw, to keep it pointed at Salyut;
- 5 is orientation in roll, to align the docking ports on the final phase of the approach;
- 6 and 8 are the DPO pitch flips to 180º and 0º - so state 6 face away from Salyut, do the burn, then state 8 to face Salyut again;
- 7 is the burn state, it's either an SKDU or retro burn, depending on that burn_seq and other parameters. burn_seq defines the speed target, for example, so state 7 knows when to stop burning;
- 9 and 10 are like 6 and 8, but it's pitch down to 90º or pitch up to 90º - this is for the initial phase of the approach, the Soyuz uses the SKDU to cancel the lateral drift since it's more efficient that way (the DPO thrusters are too weak at large distances). So if a braking burn was just made facing away from Salyut, and a lateral burn is next, it chooses state 10. Otherwise, it chooses state 8 to point at Salyut again;
- 11 is a dedicated state for that burn at 90º;
- 12 is a special case of roll alignment to point the lateral drift vector towards the ship's +Y. There will always be some lateral drift which builds up over time, because the orbits of the two ships are different. Basically since Soyuz could only pitch 90º in the down direction (due to the antenna's gimbal range and position), you want Soyuz to be moving "up" relative to Salyut, so that when it pitches down 90º, it's burning in exactly the opposite direction.
Burn_seq was my way of changing the speed targets and the sequence, so the algorithm knows when to choose each state. It always starts at 0, and depending on the inital approach speed and distance when Igla is turned on, it decides on the next value. For example, 6 is to slow down to 0.3 m/s under 200 m, and 8 is sort of a loop which redirects to burn_seq 6 if the speed gets too high. LOS burn is a counter for how many of the 90º burns have happened, because throughout the approach, there are fixed distances which trigger one of those. Every time one happens, or isn't needed, it increments. So throughout the approach, these two values guide the sequence by keeping track of where it is in the sequence.
For a ~30 km start, after states 1, 2 and 4 run once, it should first use state 12 to roll correctly, then do a 90º burn, loop on state 4, and then at 10 km or so do the first braking burn. It's also possible it has to roll again after that first 90º burn, depending on the trajectory.
Intz was something I had to come up with for state 12. I get the angle between the drift vector and Soyuz's +Y axis to know when they are aligned, but was having trouble because it all broke down when the ship is rolling, it failed to stop at the right time. So now, when Igla decides it needs to roll using state 12, it saves how much it needs to roll. Then, as state 12 rolls it, it integrates the angular velocity over time, which is equivalent to "how much has it rolled so far", this is Intz. At the appropriate accumulated value, it starts cancelling the roll. So now, instead of comparing with the actual drift vector until the difference is small enough, it's a "dumb" "roll by x degrees and it should be close enough". Closed loop vs open loop, I guess.
On paper it makes enough sense to me, but I reckon with all the different thresholds, it's kinda hanging on wires and there's a lot of potential for specific situations to break the whole thing. I think the best I can do is gradually catch as many as I can and account for them.
As a side note, I'll try to work something up for the next one to have the Vzor "off" when not needed. If it has a significant impact in fps, it shouldn't be forced on. IRL the peripheral screens have shutters, and I think they have a lid to put on the central screen.
A side question about SKD DV burns …. I saw that once you know how much DV you need to burn, say 30 m/s, by activating the accelerometer and firing the SKD when the accumulated DV in the HUD get to 30 m/s you may cut off the engine; but all this is done looking at the HUD … how this “cut off” was supposed to be performed by the crew? Using the programs that you were mentioning you are going to implement?
Or were you suppose to set the DV in the DV counter next to the reserve DV counter (i saw that it is set to 50.5 but the number can be changed with the knob below, but it never change upon firing the SKD) and upon ignition it was supposed to count down to zero, signaling the crew when to cut off the engine? or the engine was automatically cut off?
I actually haven't seen any direct references to the counter decreasing during a manual burn, but maybe I missed/forgot something. It would make sense that it did and I think that's the case, but the info I've seen is more along the lines of knowing how long a burn should take. In any case, it was also used by the automatic burns, in that case they would input the delta-v and the program would use it for the burn. It's also likely they could have a semi-auto SKDU burn: since there's a "SKDU impulse" command on the KSU, and the separate "SKDU on/off" buttons on the main panel, I'm thinking through the buttons it was fully manual, but through the KSU it would start when you commanded it but turn off when the input Delta-V is reached. The idea with the main programs (as in Manoeuvre and Descent) is they consist of several "subprograms" (like orbital orientation) and commands (like activating the accelerometer), which are turned on sequentially on a time scale. The crew was supposed to be able to command each step manually in case the timing unit failed to, so it makes sense that option would be available.
But basically I'm leaving the VC side of the accelerometer for when the programs are implemented.
I would like to discuss with you some others Soyuz issues, general topic not specific to this project of your, can I send you a PM to avoid cluttering this post?
Sure, no problem.
while the target distance on the hud is almost the same as the distance in the dokcing mfd, why the target range rate is very different from the CVEL ?
That has to do with how the distance is calculated. Angles and speeds are calculated based on distance to Salyut's centre of mass, but for the displayed distance I adjust to distance to docking port. But the docking port is some 7 m away from the centre of mass of Salyut, plus it's not very well tuned. But even at small distances it shouldn't have a big impact.
next, if you see my screenshots, sometimes you see over imposed to the main hud some weird imagines of the soyuz external green parts ... well when i was taking the screenshot i paused orbiter, than go to VC view to see the ELS display and than back to HUD view ... and upon coming back the double imagine was there, upon unpausing orbiter the superimposed imagine disappeared almost instaneusly ... (just in case you noticed and were thinking why i saved such weird imagines) ... sometime is not there as i save the screenshot immidiatly (withoug hitting F8), but sometime i forgot and i saved once back to hud view and the double imagine was there.
Only when paused, right? That has to do with the camera resetting. On HUD mode, I'm forcing it to the Vzor's point of view on every frame, because if you switch to VC, the camera position changes and it needs resetting when you come back to HUD view, I might be missing a way to separate both cameras. So it looks through the BO, since it's still located near where the seats are. But yeah, Orbiter only updates the position when you unpause.