Project Project Mercury

[Urwumpe]

If wind simulation is enabled, could also be a factor there. I noticed that my capsule was pretty strongly moving with the prevailing surface wind.

 

[n72.75]

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.

 

[BigMac]

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

 

[n72.75]

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

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?

 

[BigMac]

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?

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:

• 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

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:


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.

 

[n72.75]

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.

 

[BigMac]

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.

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?

 

[n72.75]

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?

They are in their launch positions.

 

[n72.75]

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:

• 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

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:
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.

Okay, well hopefully this is helpful to you:



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.

 

[BigMac]

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.

Very helpful!
Thanks for taking the time to put that together.
I did a bit of testing yesterday and didn't find any obvious culprits, however I have a couple of ideas as to what might be happening based on those graphs - I'll go over the data properly and do some more testing this morning.

Edit:
I think I understand what's going on now, it seems to be a combination of a couple of problems.
Firstly there seems to be the issue I initially expected with the attitudes gradually drifting outside the ASCS limits.
I've taken the data you provided and formatted it to show the pitch/yaw errors against the target attitudes. You can see that the amplitude of the pitch oscillations (red trend) gradually increases until it hits around 8 degrees, which is the limit for ASCS control:


The second issue seems to be around the slaving of the yaw gyro, which works slightly differently to pitch and roll as there are no instruments directly measuring the yaw attitude. The pitch gyro is gradually torqued at a rate equal to the orbital period to keep it in line with the local horizon, however no such torquing is done with the roll gyro (as with the capsule at the expected zero yaw the it should stay aligned with the horizon). If the capsule is not oriented correctly in yaw then an error between the roll gyro and roll horizon scanner readings will develop, roughly proportional to the sine of the yaw angle - the yaw gyro is then torqued based on a multiple of this error to gradually drive it back towards the correct angle.
The actual gain of this torquing rate isn't noted anywhere as far as I know so I've had to make a best guess, and I think it might initially have been too high leading to the possibility of the gyro being offset faster than the ASCS can respond during orbital flight. Based on your data the yaw angle starts to drift off around the start of the first slaving period, so I think this is probably the cause.

Download link has been updated with a couple of small tweaks to the ASCS orbit mode tables to address the first issue and a reduced yaw gyro torquing rate to solve the second - fingers crossed that should fix everything!

 

[n72.75]

Cool! I'll give the updated version a try later when I'm home.

 

[n72.75]

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.

 

[BigMac]

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

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.

 

[n72.75]

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.

I will update and then probably try to run through a full mission, per the flight plan.

 

[BigMac]

Hello all, just a quick update - I've now added in meshes for both launch complexes and made a couple of changes to the Atlas guidance so that it now flies in the correct orientation. For the launch complexes to be placed correctly you will need to enable the terrain flattening option in the graphics client settings.

 

[4throck]

Looks good. The untextured towers give it a 1990s "vector graphics" feel. Simple and effective

 

[n72.75]

Those look great!

 

[4throck]

Since the towers were brand new at the time, texturing is not that important. D3D9 shadows and tweaks to the metal shader might make them look more realistic....

 

[BigMac]

There are actually some very subtle textures on the towers, although they should perhaps be made a bit more prominent - in most of the images I found the towers just looked boringly red!
I like the suggestion of trying to use the metal shader - think that would definitely improve things somewhat, so I'll have a play around and see what I can do.

 

[n72.75]

Hi @BigMac

I had a bit of time this past weekend to revisit flying your addon a bit. Have you had any progress on your side since the last update?