For some brief pointers on the gyros:The parachute dynamics are unrivaled in Orbiter. Wind can make for a breezy descent, but I like it.
I also managed to find myself in need of reäligning my gyros which should be some reading for sure. Better piloting next time.
For some brief pointers on the gyros:
The main axes of the two attitude gyros (pitch and yaw readings) are free to rotate through 360 degrees, however the secondary axis (roll reading) is limited to +/-83 degrees - this is indicated by the red marks on the attiude display. Manouvering outside the roll limits, or more generally to significantly outside of orbit attitude can introduce misalignments.
The gyros will be slaved to the horizon scanners at several points during the mission which should automatically realign them immediately in pitch and roll. and more gradually in yaw. This slaving will take place as long as the gyro switch is set to "Gyro Norm", the horizon falls within the scanner field of view, and the sun is not visible to the scanner.
If you need to fly at an unusual attitude it's best to first cage the gyros and then realign them when you return to orbit attitude - the process for realigning manually would be:
- Disconnect ASCS
- Gyro switch to "Cage"
- Manouver to 0 degrees pitch/roll/yaw using the periscope
- Gyro switch to "Gyro Norm"
- Re-engage ASCS
There's no indication in the cockpit as to whether the gyro's are currently being slaved, however they will do so at the folowing points in the flight:I might be still doing this wrong.
It seems to hold a good attitude for a while but the oscillations build in amplitude over a few minutes until pitch or roll is completely upside-down.
How do I tell if the gyros are currently slaved to the sensors? Am I not waiting long enough on the last step?
Certainly seems like it's happening for some other reason in that case - some logs of the attitudes would definitely be useful to help get to the bottom of it.Definitely not using time acceleration.
I'm averaging 60-70 fps in the virtual cockpit on orbit so approx 14-17ms timestep length. I know Orbiter applies thrust for the full duration of the step, and isn't capable of resolving shorter durations (unless you do something advanced like use impulse and calculate what the effect thrust would be for the given step length).
I can run some tests with the flight recorder active if you want, logging attitude.
They are in their launch positions.Certainly seems like it's happening for some other reason in that case - some logs of the attitudes would definitely be useful to help get to the bottom of it.
I'll do some testing in the meantime to see if I can reproduce something similar.
Could I also check whether you had changed the position of any of the ASCS switches or control handles?
There's no indication in the cockpit as to whether the gyro's are currently being slaved, however they will do so at the folowing points in the flight:
I think the issues you are having are more related to the ASCS than the gyro's. During orbital flight the ASCS switches to a mode allowing it to use minimal fuel to maintain roughly the correct attitude using only readings from the attitude gyros (no rates). This means that there should be a gradual drift between +/- 3 degrees of the desired attitudes followed by a small pulse of the low torque thruster to reverse the rate in the axis - see below:
- From escape tower jettison to the assumption of orbit attitude (around five minutes after capsule separation)
- During orbital flight with a schedule of six minutes slaving followed by 14 minutes not slaving
- From 10 minutes to the programmed start of the retro sequence up until retro fire
- From retro jettison until .05G signal
View attachment 28674
If time acceleration is being used then it's possible for these pulses to last longer than indended which can lead to the rates gradually building up to the point that the ASCS can't maintain the correct attitude any more. In general if you want to use time acceleration during orbital flight I would switch off the ASCS and let the capsule drift to prevent this.
I could be completely wrong however and if this is happening without time acceleration I might need to tweak some values to prevent it.
Very helpful!Okay, well hopefully this is helpful to you:
View attachment 28676
Peak to peak on pitch oscillation is ~95 seconds.
As you can see things start to go wrong at 22:53 GET.
Unfortunately I can't get roll data with orbiters flight data recorder.
The attitude oscillations seem to me to indicate that control gain is too high, or thrusters are too strong.
I don't know how the Yaw gyros are slaved, but is it possible that there is a sign error somewhere. This one gets me a lot with Orbiter's left-handed coördinate system.
I make use heavily of oapiDebugString() to see what's going on in situations like this.
Glad to hear that's solved your issues!Well I made it to the beginning of rev 2 and all looks good so far. Attitude has been right down the middle so I'd say you solved it!
There were two things I wanted to mention that are hopefully easy fixes.
- Occasionally I will get a random CTD with no errors some minutes after booster separation. The timing coïncides exactly with the time that the booster impacts the ocean. This doesn't happen every time, but if I delete it before separation, I'm guaranteed no CTD. Looking at the crazy dance it does on impact, this might be related to touchdown point definitions, but not 100% sure.
- You should be able to set whether or not a vessel is "focusable" in the F3 menu. Users would still be able to look at the other vessels with the camera dialogue. This is up to you, just a thought.
View attachment 28689
View attachment 28690
I will update and then probably try to run through a full mission, per the flight plan.Glad to hear that's solved your issues!
I've added a quick update at the link to delete the booster on ground contact and to make the majority of the capsule components non-focusable.