FlightGear wiki - User contributions [en]

Cessna 172P/info

2026-07-02T22:56:24Z

Celesta:

<includeonly>{{infobox aircraft
| name = Cessna 172P Skyhawk
| hangar = fgdata
| image = c172p-preview2.jpg
| image2 = c172p-panel-landing.jpg
| type = Civil aircraft/Civil utility aircraft/Glider tug
| config = High wing aircraft/Fixed gear aircraft
| propulsion = Propeller aircraft/Single-engine aircraft
| manufacturer = Cessna
| authors = David Megginson/Gilberto Agostinho/Wayne Bragg/Juan Vera del Campo/onox/Fernando Barbosa/Daniel Dubreuil/Jonathan Schellhase/Israel Hernandez/Tuomas Kuosmanen/Anders Gidenstam/Waldo Kitty/algefaen
| fdm = JSBSim
| fgname = c172p
| status-fdm = 5
| status-systems = 5
| status-cockpit = 5
| status-model = 5
| ready = tutorials/checklist
| devel-repo = {{github url|user=c172p-team|repo=c172p}}
| download = {{github zip file|user=c172p-team|repo=c172p|full=1}}
| liverydbid = 70
| forumtid = 25157
| note = {{LangSwitch
| ar = هذه هيا طائرة فلايت جير الإفتراضية ويتم توزيعها كجزء من حزمة البرنامج
| ca = Aquest és l'avió predeterminat de FlightGear i es distribueix com a part del paquet base.
| de = Dies ist das FlightGear Standardflugzeug und im Basispaket der Software enthalten.
| en = This is the default FlightGear aircraft and is distributed as part of the base package.
| es = Este es el avión predeterminado de FlightGear y se distribuye como parte de la descarga de FlightGear.
| it = Questo è l'aeromobile predefinito di FlightGear ed è distribuito come parte del pacchetto di base.
| pl = Jest to domyślny samolot we FlightGear i jest rozprowadzany jako część pakietu podstawowego.
| ru = Этот самолёт является летательным аппаратом по умолчанию в FlightGear и распространяется, как часть базового пакета.
| zh = FlightGear的默认机型，并被包括在FlightGear主程序中。
}}
| wikipedia = {{LangSwitch
| en = Cessna 172
| pl = Cessna 172
| zh = Cessna 172
}}
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 172P]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Zh/Cessna 172P

2026-07-02T22:50:48Z

Celesta: /* 特性 */

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
塞斯纳 172P ''Skyhawk'' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]，于1955年首飞，至今仍在生产。塞斯纳172是至今为止生产数量最大的飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的拟真检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有5种改型，可从机型菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种危险的状态，尤其在转向第五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率更高，在涂装菜单中标记为HD（高清）。高清涂装还有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了[[ALS]]（大气光散射），则可以点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。第一次点击为白色手电筒，再点一次为红色，再点一次可关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备（Ground equipment）对话框中可以启用/禁用地面设备，包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆推到20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（按{{Key press|s}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼放下速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:50:02Z

Celesta:

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
塞斯纳 172P ''Skyhawk'' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]，于1955年首飞，至今仍在生产。塞斯纳172是至今为止生产数量最大的飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的拟真检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有5种改型，可从机型菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率更高，在涂装菜单中标记为HD（高清）。高清涂装还有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了[[ALS]]（大气光散射），则可以点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。第一次点击为白色手电筒，再点一次为红色，再点一次可关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备（Ground equipment）对话框中可以启用/禁用地面设备，包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆推到20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（按{{Key press|s}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼放下速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:40:07Z

Celesta: /* 特性 */

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率更高，在涂装菜单中标记为HD（高清）。高清涂装还有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆推到20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（按{{Key press|s}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:38:40Z

Celesta: /* 发动机启动（复杂的手动启动） */

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆推到20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（按{{Key press|s}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:38:12Z

Celesta: /* 发动机启动（复杂的手动启动） */

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆在20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（按{{Key press|s}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:37:40Z

Celesta:

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆在20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（{{Key press|S}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 油门推满
* 在55节时拉杆抬轮

=== 爬升 ===
* 不放襟翼
* 油门推满
* 空速75节

=== 巡航 ===
* 油门65%
* 混合比富油
* 空速约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 空速60节

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Atmospheric light scattering

2026-07-02T22:30:38Z

Celesta:

{{see also|ALS technical notes}}
[[File:Light scattering dec12 05.jpg|thumb|Light scattering demonstration in FlightGear]]
Atmospheric Light Scattering (ALS) is an advanced rendering framework developed for FlightGear to realistically simulate the visual effects of light passing through the Earth's atmosphere, which is enabled by default. Rather than relying on a uniform, global fog value, ALS dynamically computes light attenuation, color shifts, and scattering intensities based on the physics of light propagation, observer altitude, sun angle, and local weather patterns. This creates a highly immersive and visually authentic environment where visibility naturally changes depending on the direction and altitude from which the scene is viewed.

== Light scattering basics ==

The basic processes how light scatters in the atmosphere are [http://en.wikipedia.org/wiki/Rayleigh_scattering '''Rayleigh scattering'''] and [http://en.wikipedia.org/wiki/Mie_scattering '''Mie scattering''']. Rayleigh scattering occurs on scattering centers which are much smaller than the wavelength of light (typically the air molecules). In this limit, the outgoing light is scattered into every direction with equal likelihood (isotrope scattering), but the probability to scatter depends on the wavelength of the light - the shorter wavelengths (blue, violet) scatter more strongly. This is the cause for the color of a clear sky - there is much more diffuse Rayleigh scattering for blue light happening in the upper atmosphere than for red light, and as a result we see all the light that gets scattered out of the direct path from sun to eye as a diffuse blue glow - the sky. The same phenomenon causes the red color of sunrises - since the sun is close to the horizon, the path the light has to travel through the dense parts of the atmosphere is long and so by the time the light reaches the eye all blue light has been scattered out and only the red light remains.

Mie scattering in contrast occurs for much larger particles (water droplets for instance). In this limit, the scattering is of equal strength for all wavelength (i.e. pure Mie-scattered light is white), but the scattering is strongly directional - the scattered light prefers to go close to its original direction. Mie scattering thus tends to create bright white halos around light sources. This is illustrated in the following screenshots of a sky decomposed into the Rayleigh and Mie scattering channels:

[[File:Mie rayleigh.jpg|300px|Mie and Rayleigh scattering]]
[[File:Rayleigh.jpg|300px|Rayleigh scattering only]]
[[File:Mie.jpg|300px|Mie scattering only]]

As long as the light scattering effect is weak, a medium is called optically thin. The relevant measure is the ratio of the light attenuation length divided by the size of the medium which must be smaller than one, and the defining characteristic of an optically thin medium is that you can look through. This is certainly true for the upper atmosphere where visibility ranges are easily several hundred kilometers whereas the thickest part of the atmosphere is just about 30 km vertical size. Thus, a dark blue sky is actually the blackness of space, seen through the light blue-white glow of Rayleigh scattering.

As clouds demonstrate quite drastically, water droplets can easily make the atmosphere optically thick. In this case, light is scattered multiple times before reaching the eye, and most information on what the basic scattering process was like is lost. Dense fog looks like a uniform grey, which means there is no color information left, and no directional information where the light originally came from. We may call this regime '''diffuse scattering'''.

Actually, it is not quite true that diffuse scattering retains no color information. A sunrise beneath an overcast cloud cover looks blue-grey rather than red, thus there are subtle color changes of the incoming light as it filters through an optically thick layer.

== Atmospheric haze ==

=== General considerations ===

What makes the problem complicated to solve in practice is that the only thing that can be calculated reliably is the density of air molecules in the atmosphere as a function of altitude, but there are only one ingredient in the light scattering problem. Dust or water vapour are at least equally important, but their distribution in the atmosphere cannot be cast into a simple form - it is in general a full 4-dim function of space and time, equal to the evolution of the weather itself. The information about the distribution of haze must then come from the weather system.

Getting a semi-realistic haze distribution is important for rendering a scene. A normal haze distribution in the atmosphere can not be characterized by a single value of the visibility range - the visibility range depends on position and view direction. Imagine you are 10 km high and the forward visibility is an (unrealistically small) 10 km. The visibility range looking down will typically be a lot less since the atmosphere gets denser as we go down in altitude, and hence there is a lot more light scattering. Looking up on the other hand the visibility will be much more than 10 km since the density decreases. Or imagine a second case with a 1 km thick fog layer with 500 m visibility on the ground. Above the layer, the visibility can be 50 km. However, it will be impossible to see the ground beneath the fog, only mountains reaching above the fog layer will be visible. The following two screenshots illustrate the situation:

[[File:Ground fog02.jpg|400px|Thin ground fog layer]] [[File:Ground fog01.jpg|400px|Dense ground gof layer]]

Setting a global visibility in the scene to a value of either 50 km or 500 m will never result in this behaviour. Thus, once we want to render anything resembling realistic haze distributions, visibility along any ray must be a property of the whole scene rather than the position of the aircraft.

The haze problem can be approximated by observing the following points:

* The vertical structure of the atmosphere changes usually much faster than the horizontal structure. A fog bank may be 500 m thick, but it is unlikely to be just 500 m wide. Most realistic haze layers are almost constant across a range O(10) km, i.e. to a good first approximation one can model only the vertical structure of the atmosphere and have the atmosphere horizontally constant in each frame and change the whole horizontal structure of the atmosphere per frame dependent on current position. This doesn't take into account that a haze layer may be seen from above to have a finite extension.

* Most dust and water vapour is found in the lowest convective layer of the atmosphere, i.e. beneath the lowest cloud layer, since this layer has actual contact with the surface as a source of water vapour and dust, but there is no effective transport of dust across the lowest inversion layer. Thus, most situations are approximated well by a low visibility layer close to the ground with a high visibility layer above. This neglects situations in which a second optically thick layer may be in the scene at higher altitudes.

* Compared to diffuse scattering, the effect of Rayleigh and Mie scattering is much less pronounced, as these apply to optically thin media with hardly any light attenuation. Thus, one can to a good approximation base the whole fog fading with distance on diffuse scattering. This neglects phenomena like the [http://en.wikipedia.org/wiki/Blue_moon#Visibly_blue_moon Blue Moon] which are caused by almost pure Rayleigh scattering in the absence of diffuse scattering.

=== The color of the horizon ===

An interesting problem with a surprising solution is how the horizon should be coloured. Suppose it is noon, the sun is right above the scene, we stand on the seashore and look towards the horizon - what do we see? If there were no atmosphere, we'd see the darkness of space (as pictures from the surface of Moon demonstrate nicely). Since there is atmosphere, we see black, fogged by the atmosphere between us and the edge of the atmosphere.

If we approximate the atmosphere by a 20 km thick layer with a constant density, the horizontal view ray exits the atmosphere after passing about 500 km of air. If the air is very clean and hence only Rayleigh scattering present, the horizon is a relatively dark blue. Even small amounts of fog (a visibility of 500 km is quite good!) change this to a light blue.

If the visibility is somewhat less, i.e. between ~30 and 400 km, the horizon is a brilliant white. Every fog particle along the ray is fully illuminated from above, but we cannot see through the atmosphere, as the visibility is less than the distance we'd need to see.

Once the visibility drops below about 30 km, it is however no longer true that every fog particle is fully illuminated - a lot of light now gets absorbed in the upper layers of the atmosphere before it can reach fog particles along the view ray, and hence the horizon becomes grey. Eventually, under an overcast sky and in thick haze, this turns into a dark blue-grey.

Thus, as the visibility increases from zero to infinity, the horizon first gets lighter until it reaches a brilliant white, then it darkens again.

=== Color shifts of the terrain ===

Rayleigh scattering on air molecules and small aerosol particles does not only cause the blue color of the sky - the same effect that occurs when looking through a column of air into space also occurs when looking through air onto terrain. Rayleigh scattering causes distant objects to appear at different colors.

The actual color of an object seen in the distance is a competition between in- and out scattering. Along the ray of light connecting eye and the object, light coming from the object is scattered out, and as Rayleigh scattering preferentially affects the short wavelength, the remaining light is shifted towards red. However, at the same time, light hitting the air molecules from above is scattered into the direction of the eye, and for the same reason, this light is preferentially blue. As a result, distant terrain appears as if covered by a blue haze, but the colors underneath the haze are subtly shifted towards red.

An example of increasingly stronger Rayleigh scattering on the terrain rendered in Flightgear is shown below:

[[File:Rayleigh off.jpg|300px|No Rayleigh scattering]]
[[File:Rayleigh half.jpg|300px|Medium Rayleigh scattering]]
[[File:Rayleigh full.jpg|300px|Strong Rayleigh scattering]]

As of Flightgear 3.3, the Atmospheric Light Scattering framework simulates Rayleigh scattering on the terrain based on the visibility parameters of the scene and an air pollution factor at high shader effect quality level. The combined effect of Rayleigh haze, color shifts due to out-scattering and diffuse haze can lead to a very subtle variation of color across the visible and partially haze-covered terrain

[[File:Rayleigh blue.jpg|500px|center|Different hazes in combination]]

=== Visibility and fog function ===

In aviation weather, the visibility is defined as the distance out to which objects are still recognizable in fog or haze. In physics, the visibility is usually defined as one attenuation length of the light, i.e. the distance by which only the fraction of 1/e or about 36% of the original light is left. The two definitions are obviously not identical - it appears that about 2-3 attenuation lengths are needed to meet the criterion that distinct objects are no longer recognized (this also depends on other factors).

In reality, in a fog of constant density, the fraction of the original light (pixel color) left after a distance ''d'' is exp[-''d''/λ] - this is exponential fogging. Since the visibility range is about 3λ, this implies for 3d rendering that the majority of scenery loaded will be more than 80% fogged and badly visible. Since this is very inefficient, the pure exponential fogging is not always used.

An alternative is quadratic exponential fogging, i.e. a function ~exp[-''d^2''/λ^2]. This leads to less fogging for ''d''<λ but much more fogging for ''d''>λ and thus the visible terrain is less fogged whereas the faraway terrain is rapidly becoming so strongly fogged that it doesn't need to be loaded - in essence it tends to makes terrain either visible or not.

A different strategy is exponential fading with a cutoff, i.e. a function ~exp[-''d''/λ - ''d^4''/λ^4] - this fogs with a physically correct attenuation within the visibility range but cuts off everything beyond that range rapidly to that it doesn't have to be loaded. The choice of fog function is hence a balance between fast rendering and realism.

== Basic atmosphere model elements ==

Translated into a rendering problem, one can identify the following relevant elements

* The skydome simulates the scattering in an optically thin atmosphere in the absence of haze layers. As such, it takes into account Rayleigh and Mie scattering with the parameters adjusted to account for the water vapour and dust distribution above the current aircraft altitude. The current skydome shader is based on [http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html work by Sean O'Neil] and is described there (in case you're interested in O'Neil's article - the reason why he is able to do what he describes in ''Eliminating One Dimension'' is that for realistic rendering distances one can neglect the full curvature of earth and Taylor-expand the expressions in the curvature, his result can then be derived analytically). Extra diffuse high-altitude layers can just be 'painted' onto the skydome.

* Since, for an exponential decreasing atmosphere density, the scattering integrals can be solved analytically, an extra Rayleigh haze simulating sky-blue in-scattering of light is applied to the terrain before diffuse fogging, and based on the same integrals, the redshift of the terrain underneath is computed.

* A ground haze layer of given thickness and ground visibility takes care of simulating ground fog banks and visibility in the lowest convection layer. This simulates diffuse scattering only needs to enter the computations of both the skydome and the terrain shaders.

* An aloft layer simulates diffuse scattering above the ground haze layer, also simulating only diffuse scattering. Since the visual impression for anything but large distances is dominated by the ground haze layer, the aloft layer visibility can be modelled as a function of aircraft altitude without creating an unrealistic impression. The aloft layer never obscures the skydome, as its visibility range is supposed to account for the atmosphere looking down, but never looking up where the visibility is much better.

* The really optically thick clouds are drawn by the weather system as separate models into the scene.

== Perception ==

One crucial thing to remember when dealing with light attenuation is that what we see is '''not''' physical light intensity. To give an example, the light intensity beneath an overcast sky at dawn is easily a factor 2500 less than the light intensity in the bright noon sun. However, dividing an rgb vector of (1,1,1) (white light) by 2500 and using the result for lighting the overcast dawn results in a pitch black scene. The reason is that the eye adapts to different light intensities and that in essence perception weighs intensities over a wide range not linear but logarithmically, a phenomenon known as the [http://en.wikipedia.org/wiki/Weber-Fechner_Law Weber-Fechner law].

Another perception effect is that contrasts are dynamically adjusted. Usually the brightest object in the visual field is assigned the color white, the darkest the color black, and all other shades are assigned between. This means that the raw intensity range in the scene has to be compressed (e.g. by exposure filtering) into a narrower range by dimming the highest intensities and enhancing the lowest intensities. The following screenshots compare the raw intensity results with the perception-filtered results:

[[File:Perception1.jpg|400px|Before perception filtering]]
[[File:Perception2.jpg|400px|After perception filtering]]

Perception effects require thus some amount of postprocessing in the shaders.

== Light scattering during the day ==

When the sun is high enough in the sky, the situation to render is as follows: All light intersects with the terrain with a comparatively large angle. This means that the curvature of earth doesn't make a difference - light intersecting with a level surface at 55 degrees isn't differently colored or much changed in intensity from light intersecting at 56 degrees, because the pathlengths through the atmosphere do not change much. This means that the whole scene can be rendered in spatially homogeneous light and all that matters is the vertical structure of light scattering and absorption in the atmosphere, which simplifies the rendering problem considerably.

Thus, light penetrates the thin upper atmosphere, as it filters through, Rayleigh and some Mie scattering create the blue sky. Dependent on the model for the amount of high haze and water vapour to be specified by the weather system, this is handled by the skydome shader.

As the light reaches the first significant cloud layer, light intensity is much reduced. As clouds are drawn outside the terrain and skydome shading codes, this can not be explicitly computed by the shader, neither is it computationally feasible to compute the shadow cast by each cloudlet by ray tracing in real time. Thus, the relevant parameters (<tt>'''rendering/scene/scattering'''</tt> for the light intensity reduction at the position of the aircraft and <tt>'''/environment/surface/scattering'''</tt> for the light reduction on the ground) must be modelled by the weather system (which knows the cloud layer position) and passed to the shaders. The visual difference between shaded terrain and unshaded terrain is illustrated by the following two screenshots:

[[File:Cloudshade01.jpg|400px|No terrain shading by clouds]] [[File:Cloudshade02.jpg|400px|Terrain shading by clouds]]

After passing through the cloud layer (usually the lowest layer beneath which the ground haze layer starts), the light is attenuated due to the diffuse scattering in the layer, which leads to additional intensity reduction by fog self-shading which can be computed in the shader.

This, however, is tricky, because fog does not really have a position, rather what the eye sees is the integrated effect of fog along a ray, and so the brightness of fog is really a weighted integral of fog brightness along the whole ray. This, however, can be approximated by taking the brightness at one attenuation length as a proxy (incidentially, this is the reason that two scattering parameters for the effect of clouds are passed - the light reduction at the aircraft position is a better proxy for fog shadowing due to clouds, the exact position-dependent light reduction can be used for the ground which has a definite position).

The altitude-dependent light reduction due to the clouds is the first instance of the '''lightfield''' technique, i.e. that the sunlight is represented as a series of functions r(x,y,z), g(x,y,z), b(x,y,z) in which the individual color channels are functions of vertex position in the scene.

=== Diffuse skylight ===

While the Sun is the main source of light during the day, Rayleigh scattering actually makes the whole sky a source of diffuse, sky-blue light coming predominantly from above. This diffuse skylight is especially important for the perception of glossy surfaces. Usually we identify these by their sharp specular reflections. However, using only the Sun as directional light source, a surface in shadow or facing away from the Sun has no specular reflection at all. Yet in reality, such surfaces still appear glossy, because they reflect the diffuse illumination coming from the sky.

Implementing this effect in the rendering of models makes a subtle but important difference in how a glossy surface appears when facing away from the sun, as the two following screenshots illustrate:

[[File:Diffuse skylight off.jpg|400px|Glossy surface rendered without skylight]] [[File:Diffuse skylight on.jpg|400px|Glossy surface rendered with skylight]]

== Light scattering at dawn / dusk ==

For low sun, one can no longer assume that the scene is illuminated in homogeneous light or that terrain altitude does not matter, because both the path of light in the atmosphere and the shading due to the spherical shape of earth play a role. To see this, compare the sun just at the horizon with the sun one degree below the horizon - in the first case there is direct sunlight, in the second case there is not, and so a small change in sun angle makes an enormous difference in lighting.

In fact, the apparent sun position relative to the horizon (and thus the light) is much dependent on altitude - mountaintops can be observed in sunlight while the rest of the terrain is still dark (a phenomenon known in German as [http://de.wikipedia.org/wiki/Alpenglühen Alpenglühen]). This is even more apparent when looking at high-altitude clouds. The following screenshots show the effect in Flightgear:

[[File:Alpine glow.jpg|400 px|While the valleys are still dark, the high mountain slopes already see the first direct sunlight]]
[[File:Predawn-cloud-glow.jpg|400px|Predawn high altitude cloud glow]]

Similarly, from high altitude the curvature of earth is apparent by the terrain (or haze in the direction towards the sun being more brightly illuminated than the terrain or haze away from the sun.

Short of directly computing the light passing through the atmosphere, these effects can be taken into account by using lightfields, i.e. by changing the color and intensity of the sunlight dependent on the position and altitude of the illuminated vertex. However, even computing parametrized lightfields make a significant performance impact as compared to the rendering situation at noon.

Unfortunately, the lightfield scheme used to render the light color combined with the scheme used to determine cloud shading is not guaranteed to give realistic effects. In reality for instance, a low sun can sometimes illuminate a layer from below. Whether this is possible or not depends on how far the layer extends - if it extends all the way to the horizon, it can never be illuminated from below, but if it terminates before, this is possible. It also depends on the terrain - there might be a chain of mountains far away which blocks the sun. In order to get the situation right, the weather system would have to be able to determine the cloud cover ~200 km away from the current position, but in Flightgear typically neither the terrain nor the weather at such distances is known.

Another effect which is currently not addressed adequately is the inter-cloud shading (clouds casting shadows on other clouds). Due to the layer structure of clouds, at noon this is usually not a big issue and only the self-shading of clouds is relevant, but for a low sun inter-cloud shading (and fog being shaded by clouds) is often very pronounced in reality.

Contrary to common misconceptions, the sky itself doesn't necessarily become red-orange for a low sun - a clear sky remains usually dark blue, changing to light blue. The elements visible during a sunrise are:

* Rayleigh scattering in the upper atmosphere, coloring the sky itself red if dust or aerosols are present (for instance after a volcano eruption or in a region with polluted air) - this is almost absent in clean air

* Mie scattering of red-orange Rayleigh light in the lower atmosphere - this specifically creates a red-golden halo around the rising sun and is absent when looking away from the sun

* Diffuse scattering of red-orange light in the ground haze fog - this contribution colors all directions almost equally, it can also be seen by a viewer facing away from the sun.

* Clouds being illuminated by red-orange light - high clouds are translucent and can be seen against the sun, lower dense clouds block the sunlight and appear dark against the sun, but bright looking away from the sun. Most spectacular sunset pictures show red-orange clouds glowing in front of a relatively dark clear sky.

The following screenshots of a very coloured sunrise in which successively the diffuse scattering and the Mie scattering components are removed illustrate this - in a clear, Rayleigh dominated sky the blue sky color essentially remains:

[[File:Sunrise all.jpg|300px|Diffuse, Mie and Rayleigh scattering]]
[[File:Sunrise mie rayleigh.jpg|300px|Mie and Rayleigh scattering]]
[[File:Sunrise rayleigh.jpg|300px|Rayleigh scattering only]]

The difference between diffuse and Mie scattering are more apparent when looking 90 degrees away from the sun. The diffuse component is unchanged, however the Mie component shows a dependence on view direction:

[[File:Sunrise side all.jpg|300px|Diffuse, Mie and Rayleigh scattering]]
[[File:Sunrise side mie.jpg|300px|Mie and Rayleigh scattering]]

== Predawn light scattering ==

Before sunrise, there is no direct light from the sun available, all light which reaches the ground has scattered at least once in the upper atmosphere (which is already illuminated). In the context of the [http://en.wikipedia.org/wiki/Phong_reflection_model Phong reflection model], this means that the diffuse and specular lighting is absent.

Since Rayleigh scattering dominates the upper atmosphere light scattering, predawn light is usually blue. However, this is not the whole story, as the perception of low intensity light is also biased towards blue (this is known as the [http://en.wikipedia.org/wiki/Purkinje_effect Purkinje effect] and the reason why moonlit scenes appear bluish in spite of the fact that moonlight is just reflected sunlight and has the same spectrum). The sudden change to the red direct light of the rising sun can create for a short time spectacular contrasts.

However, in the presence of a high cloud or haze layer, direct light can be diffuse scattered towards the ground. In this case, the ground predawn light is actually brighter than for a clear sky, and it has a red color. The following screenshots illustrate this in Flightgear:

[[File:Predawn-scatter1.jpg|400px|Usual predawn light]]
[[File:Predawn-scatter2.jpg|400px|Predawn light with high haze layer]]

== Light scattering on clouds ==

Despite being rendered technically in a completely different way from haze and fog (texture stacks vs. fog function in terrain shaders), the physics of light scattering on clouds is no different from the physics of light scattering in haze. Mie and diffuse scattering are the main mechanisms on water droplets. The thickness of the cloud makes all the difference here.

We have already discussed the mean effect of light attenuation on a cloud layer, let's look now at some specifics.

=== Mie scattering on thin clouds ===

When a thick cloud is before the sun, it absorbs the sunlight and the cloud appears dark, which is the effect of diffuse scattering. However, when a thin cloud is illuminated from behind, it glows brilliant white during the day or red-golden during sunrise. This is the effect of forward scattering - the light scattering is strong as long as the scattering angle is small and sun, cloud and eye are approximately lined up. As with haze, Mie scattering creates a bright halo in thin cloud cover.

At daytime, this creates a whiteout of a cloud when the sun is right behind it. If other, more dense clouds are also in the scene, this creates an impressive play of light and shadow:

[[File:Cloud_mie03.jpg|500px|center|Mie scattering during the day]]

Interestingly enough, cloud dominated by Mie scattering appear a relatively dark grey (as if they were in shadow) when seen from the side, even when they are fully illuminated. This is caused by the low probability of light scattered to large angles - since all light is focused forward, the side of the cloud becomes dark.

At sunrise and sunset, the effect of Mie scattering is even more prominent - since the direct sunlight coming through the upper atmosphere is red-golden due to the effect of Rayleigh scattering, the Mie-halo created by light scattering in the clouds is also coloured. Combined with diffuse shading on denser clouds, this generates very vivid colors which change quickly as the sun rises higher and both light intensity and hue change.

[[File:Cloud_mie01.jpg|400px|Mie scattering on thin clouds during sunrise]]
[[File:Cloud_mie02.jpg|400px|Mie scattering on thin clouds during sunrise, a bit later]]

Mie scattering is essentially absent whenever a cloud becomes opaque, i.e. when it is larger than the light attenuation length in the cloud.

== Latest version ==

The latest version of the project code is found in the [https://gitlab.com/flightgear/fgdata FGData master branch].

== Related content ==
* [[A local weather system]]
* [[Procedural Texturing]]
* [[ALS technical notes]]

== Further reading ==

* [http://www.science-and-fiction.org/rendering/als.html Atmospheric Light Scattering] (general overview and gallery)
* [http://www.science-and-fiction.org/rendering/aurora.html Aurora Borealis in ALS]

[[Category:Atmospheric light scattering shader]]

Atmospheric light scattering

2026-07-02T22:26:21Z

Celesta: heading

{{see also|ALS technical notes}}
[[File:Light scattering dec12 05.jpg|thumb|Light scattering demonstration in FlightGear]]
Atmospheric Light Scattering (ALS) is an advanced rendering framework developed for FlightGear to realistically simulate the visual effects of light passing through the Earth's atmosphere. Rather than relying on a uniform, global fog value, ALS dynamically computes light attenuation, color shifts, and scattering intensities based on the physics of light propagation, observer altitude, sun angle, and local weather patterns. This creates a highly immersive and visually authentic environment where visibility naturally changes depending on the direction and altitude from which the scene is viewed.

== Light scattering basics ==

The basic processes how light scatters in the atmosphere are [http://en.wikipedia.org/wiki/Rayleigh_scattering '''Rayleigh scattering'''] and [http://en.wikipedia.org/wiki/Mie_scattering '''Mie scattering''']. Rayleigh scattering occurs on scattering centers which are much smaller than the wavelength of light (typically the air molecules). In this limit, the outgoing light is scattered into every direction with equal likelihood (isotrope scattering), but the probability to scatter depends on the wavelength of the light - the shorter wavelengths (blue, violet) scatter more strongly. This is the cause for the color of a clear sky - there is much more diffuse Rayleigh scattering for blue light happening in the upper atmosphere than for red light, and as a result we see all the light that gets scattered out of the direct path from sun to eye as a diffuse blue glow - the sky. The same phenomenon causes the red color of sunrises - since the sun is close to the horizon, the path the light has to travel through the dense parts of the atmosphere is long and so by the time the light reaches the eye all blue light has been scattered out and only the red light remains.

Mie scattering in contrast occurs for much larger particles (water droplets for instance). In this limit, the scattering is of equal strength for all wavelength (i.e. pure Mie-scattered light is white), but the scattering is strongly directional - the scattered light prefers to go close to its original direction. Mie scattering thus tends to create bright white halos around light sources. This is illustrated in the following screenshots of a sky decomposed into the Rayleigh and Mie scattering channels:

[[File:Mie rayleigh.jpg|300px|Mie and Rayleigh scattering]]
[[File:Rayleigh.jpg|300px|Rayleigh scattering only]]
[[File:Mie.jpg|300px|Mie scattering only]]

As long as the light scattering effect is weak, a medium is called optically thin. The relevant measure is the ratio of the light attenuation length divided by the size of the medium which must be smaller than one, and the defining characteristic of an optically thin medium is that you can look through. This is certainly true for the upper atmosphere where visibility ranges are easily several hundred kilometers whereas the thickest part of the atmosphere is just about 30 km vertical size. Thus, a dark blue sky is actually the blackness of space, seen through the light blue-white glow of Rayleigh scattering.

As clouds demonstrate quite drastically, water droplets can easily make the atmosphere optically thick. In this case, light is scattered multiple times before reaching the eye, and most information on what the basic scattering process was like is lost. Dense fog looks like a uniform grey, which means there is no color information left, and no directional information where the light originally came from. We may call this regime '''diffuse scattering'''.

Actually, it is not quite true that diffuse scattering retains no color information. A sunrise beneath an overcast cloud cover looks blue-grey rather than red, thus there are subtle color changes of the incoming light as it filters through an optically thick layer.

== Atmospheric haze ==

=== General considerations ===

What makes the problem complicated to solve in practice is that the only thing that can be calculated reliably is the density of air molecules in the atmosphere as a function of altitude, but there are only one ingredient in the light scattering problem. Dust or water vapour are at least equally important, but their distribution in the atmosphere cannot be cast into a simple form - it is in general a full 4-dim function of space and time, equal to the evolution of the weather itself. The information about the distribution of haze must then come from the weather system.

Getting a semi-realistic haze distribution is important for rendering a scene. A normal haze distribution in the atmosphere can not be characterized by a single value of the visibility range - the visibility range depends on position and view direction. Imagine you are 10 km high and the forward visibility is an (unrealistically small) 10 km. The visibility range looking down will typically be a lot less since the atmosphere gets denser as we go down in altitude, and hence there is a lot more light scattering. Looking up on the other hand the visibility will be much more than 10 km since the density decreases. Or imagine a second case with a 1 km thick fog layer with 500 m visibility on the ground. Above the layer, the visibility can be 50 km. However, it will be impossible to see the ground beneath the fog, only mountains reaching above the fog layer will be visible. The following two screenshots illustrate the situation:

[[File:Ground fog02.jpg|400px|Thin ground fog layer]] [[File:Ground fog01.jpg|400px|Dense ground gof layer]]

Setting a global visibility in the scene to a value of either 50 km or 500 m will never result in this behaviour. Thus, once we want to render anything resembling realistic haze distributions, visibility along any ray must be a property of the whole scene rather than the position of the aircraft.

The haze problem can be approximated by observing the following points:

* The vertical structure of the atmosphere changes usually much faster than the horizontal structure. A fog bank may be 500 m thick, but it is unlikely to be just 500 m wide. Most realistic haze layers are almost constant across a range O(10) km, i.e. to a good first approximation one can model only the vertical structure of the atmosphere and have the atmosphere horizontally constant in each frame and change the whole horizontal structure of the atmosphere per frame dependent on current position. This doesn't take into account that a haze layer may be seen from above to have a finite extension.

* Most dust and water vapour is found in the lowest convective layer of the atmosphere, i.e. beneath the lowest cloud layer, since this layer has actual contact with the surface as a source of water vapour and dust, but there is no effective transport of dust across the lowest inversion layer. Thus, most situations are approximated well by a low visibility layer close to the ground with a high visibility layer above. This neglects situations in which a second optically thick layer may be in the scene at higher altitudes.

* Compared to diffuse scattering, the effect of Rayleigh and Mie scattering is much less pronounced, as these apply to optically thin media with hardly any light attenuation. Thus, one can to a good approximation base the whole fog fading with distance on diffuse scattering. This neglects phenomena like the [http://en.wikipedia.org/wiki/Blue_moon#Visibly_blue_moon Blue Moon] which are caused by almost pure Rayleigh scattering in the absence of diffuse scattering.

=== The color of the horizon ===

An interesting problem with a surprising solution is how the horizon should be coloured. Suppose it is noon, the sun is right above the scene, we stand on the seashore and look towards the horizon - what do we see? If there were no atmosphere, we'd see the darkness of space (as pictures from the surface of Moon demonstrate nicely). Since there is atmosphere, we see black, fogged by the atmosphere between us and the edge of the atmosphere.

If we approximate the atmosphere by a 20 km thick layer with a constant density, the horizontal view ray exits the atmosphere after passing about 500 km of air. If the air is very clean and hence only Rayleigh scattering present, the horizon is a relatively dark blue. Even small amounts of fog (a visibility of 500 km is quite good!) change this to a light blue.

If the visibility is somewhat less, i.e. between ~30 and 400 km, the horizon is a brilliant white. Every fog particle along the ray is fully illuminated from above, but we cannot see through the atmosphere, as the visibility is less than the distance we'd need to see.

Once the visibility drops below about 30 km, it is however no longer true that every fog particle is fully illuminated - a lot of light now gets absorbed in the upper layers of the atmosphere before it can reach fog particles along the view ray, and hence the horizon becomes grey. Eventually, under an overcast sky and in thick haze, this turns into a dark blue-grey.

Thus, as the visibility increases from zero to infinity, the horizon first gets lighter until it reaches a brilliant white, then it darkens again.

=== Color shifts of the terrain ===

Rayleigh scattering on air molecules and small aerosol particles does not only cause the blue color of the sky - the same effect that occurs when looking through a column of air into space also occurs when looking through air onto terrain. Rayleigh scattering causes distant objects to appear at different colors.

The actual color of an object seen in the distance is a competition between in- and out scattering. Along the ray of light connecting eye and the object, light coming from the object is scattered out, and as Rayleigh scattering preferentially affects the short wavelength, the remaining light is shifted towards red. However, at the same time, light hitting the air molecules from above is scattered into the direction of the eye, and for the same reason, this light is preferentially blue. As a result, distant terrain appears as if covered by a blue haze, but the colors underneath the haze are subtly shifted towards red.

An example of increasingly stronger Rayleigh scattering on the terrain rendered in Flightgear is shown below:

[[File:Rayleigh off.jpg|300px|No Rayleigh scattering]]
[[File:Rayleigh half.jpg|300px|Medium Rayleigh scattering]]
[[File:Rayleigh full.jpg|300px|Strong Rayleigh scattering]]

As of Flightgear 3.3, the Atmospheric Light Scattering framework simulates Rayleigh scattering on the terrain based on the visibility parameters of the scene and an air pollution factor at high shader effect quality level. The combined effect of Rayleigh haze, color shifts due to out-scattering and diffuse haze can lead to a very subtle variation of color across the visible and partially haze-covered terrain

[[File:Rayleigh blue.jpg|500px|center|Different hazes in combination]]

=== Visibility and fog function ===

In aviation weather, the visibility is defined as the distance out to which objects are still recognizable in fog or haze. In physics, the visibility is usually defined as one attenuation length of the light, i.e. the distance by which only the fraction of 1/e or about 36% of the original light is left. The two definitions are obviously not identical - it appears that about 2-3 attenuation lengths are needed to meet the criterion that distinct objects are no longer recognized (this also depends on other factors).

In reality, in a fog of constant density, the fraction of the original light (pixel color) left after a distance ''d'' is exp[-''d''/λ] - this is exponential fogging. Since the visibility range is about 3λ, this implies for 3d rendering that the majority of scenery loaded will be more than 80% fogged and badly visible. Since this is very inefficient, the pure exponential fogging is not always used.

An alternative is quadratic exponential fogging, i.e. a function ~exp[-''d^2''/λ^2]. This leads to less fogging for ''d''<λ but much more fogging for ''d''>λ and thus the visible terrain is less fogged whereas the faraway terrain is rapidly becoming so strongly fogged that it doesn't need to be loaded - in essence it tends to makes terrain either visible or not.

A different strategy is exponential fading with a cutoff, i.e. a function ~exp[-''d''/λ - ''d^4''/λ^4] - this fogs with a physically correct attenuation within the visibility range but cuts off everything beyond that range rapidly to that it doesn't have to be loaded. The choice of fog function is hence a balance between fast rendering and realism.

== Basic atmosphere model elements ==

Translated into a rendering problem, one can identify the following relevant elements

* The skydome simulates the scattering in an optically thin atmosphere in the absence of haze layers. As such, it takes into account Rayleigh and Mie scattering with the parameters adjusted to account for the water vapour and dust distribution above the current aircraft altitude. The current skydome shader is based on [http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html work by Sean O'Neil] and is described there (in case you're interested in O'Neil's article - the reason why he is able to do what he describes in ''Eliminating One Dimension'' is that for realistic rendering distances one can neglect the full curvature of earth and Taylor-expand the expressions in the curvature, his result can then be derived analytically). Extra diffuse high-altitude layers can just be 'painted' onto the skydome.

* Since, for an exponential decreasing atmosphere density, the scattering integrals can be solved analytically, an extra Rayleigh haze simulating sky-blue in-scattering of light is applied to the terrain before diffuse fogging, and based on the same integrals, the redshift of the terrain underneath is computed.

* A ground haze layer of given thickness and ground visibility takes care of simulating ground fog banks and visibility in the lowest convection layer. This simulates diffuse scattering only needs to enter the computations of both the skydome and the terrain shaders.

* An aloft layer simulates diffuse scattering above the ground haze layer, also simulating only diffuse scattering. Since the visual impression for anything but large distances is dominated by the ground haze layer, the aloft layer visibility can be modelled as a function of aircraft altitude without creating an unrealistic impression. The aloft layer never obscures the skydome, as its visibility range is supposed to account for the atmosphere looking down, but never looking up where the visibility is much better.

* The really optically thick clouds are drawn by the weather system as separate models into the scene.

== Perception ==

One crucial thing to remember when dealing with light attenuation is that what we see is '''not''' physical light intensity. To give an example, the light intensity beneath an overcast sky at dawn is easily a factor 2500 less than the light intensity in the bright noon sun. However, dividing an rgb vector of (1,1,1) (white light) by 2500 and using the result for lighting the overcast dawn results in a pitch black scene. The reason is that the eye adapts to different light intensities and that in essence perception weighs intensities over a wide range not linear but logarithmically, a phenomenon known as the [http://en.wikipedia.org/wiki/Weber-Fechner_Law Weber-Fechner law].

Another perception effect is that contrasts are dynamically adjusted. Usually the brightest object in the visual field is assigned the color white, the darkest the color black, and all other shades are assigned between. This means that the raw intensity range in the scene has to be compressed (e.g. by exposure filtering) into a narrower range by dimming the highest intensities and enhancing the lowest intensities. The following screenshots compare the raw intensity results with the perception-filtered results:

[[File:Perception1.jpg|400px|Before perception filtering]]
[[File:Perception2.jpg|400px|After perception filtering]]

Perception effects require thus some amount of postprocessing in the shaders.

== Light scattering during the day ==

When the sun is high enough in the sky, the situation to render is as follows: All light intersects with the terrain with a comparatively large angle. This means that the curvature of earth doesn't make a difference - light intersecting with a level surface at 55 degrees isn't differently colored or much changed in intensity from light intersecting at 56 degrees, because the pathlengths through the atmosphere do not change much. This means that the whole scene can be rendered in spatially homogeneous light and all that matters is the vertical structure of light scattering and absorption in the atmosphere, which simplifies the rendering problem considerably.

Thus, light penetrates the thin upper atmosphere, as it filters through, Rayleigh and some Mie scattering create the blue sky. Dependent on the model for the amount of high haze and water vapour to be specified by the weather system, this is handled by the skydome shader.

As the light reaches the first significant cloud layer, light intensity is much reduced. As clouds are drawn outside the terrain and skydome shading codes, this can not be explicitly computed by the shader, neither is it computationally feasible to compute the shadow cast by each cloudlet by ray tracing in real time. Thus, the relevant parameters (<tt>'''rendering/scene/scattering'''</tt> for the light intensity reduction at the position of the aircraft and <tt>'''/environment/surface/scattering'''</tt> for the light reduction on the ground) must be modelled by the weather system (which knows the cloud layer position) and passed to the shaders. The visual difference between shaded terrain and unshaded terrain is illustrated by the following two screenshots:

[[File:Cloudshade01.jpg|400px|No terrain shading by clouds]] [[File:Cloudshade02.jpg|400px|Terrain shading by clouds]]

After passing through the cloud layer (usually the lowest layer beneath which the ground haze layer starts), the light is attenuated due to the diffuse scattering in the layer, which leads to additional intensity reduction by fog self-shading which can be computed in the shader.

This, however, is tricky, because fog does not really have a position, rather what the eye sees is the integrated effect of fog along a ray, and so the brightness of fog is really a weighted integral of fog brightness along the whole ray. This, however, can be approximated by taking the brightness at one attenuation length as a proxy (incidentially, this is the reason that two scattering parameters for the effect of clouds are passed - the light reduction at the aircraft position is a better proxy for fog shadowing due to clouds, the exact position-dependent light reduction can be used for the ground which has a definite position).

The altitude-dependent light reduction due to the clouds is the first instance of the '''lightfield''' technique, i.e. that the sunlight is represented as a series of functions r(x,y,z), g(x,y,z), b(x,y,z) in which the individual color channels are functions of vertex position in the scene.

=== Diffuse skylight ===

While the Sun is the main source of light during the day, Rayleigh scattering actually makes the whole sky a source of diffuse, sky-blue light coming predominantly from above. This diffuse skylight is especially important for the perception of glossy surfaces. Usually we identify these by their sharp specular reflections. However, using only the Sun as directional light source, a surface in shadow or facing away from the Sun has no specular reflection at all. Yet in reality, such surfaces still appear glossy, because they reflect the diffuse illumination coming from the sky.

Implementing this effect in the rendering of models makes a subtle but important difference in how a glossy surface appears when facing away from the sun, as the two following screenshots illustrate:

[[File:Diffuse skylight off.jpg|400px|Glossy surface rendered without skylight]] [[File:Diffuse skylight on.jpg|400px|Glossy surface rendered with skylight]]

== Light scattering at dawn / dusk ==

For low sun, one can no longer assume that the scene is illuminated in homogeneous light or that terrain altitude does not matter, because both the path of light in the atmosphere and the shading due to the spherical shape of earth play a role. To see this, compare the sun just at the horizon with the sun one degree below the horizon - in the first case there is direct sunlight, in the second case there is not, and so a small change in sun angle makes an enormous difference in lighting.

In fact, the apparent sun position relative to the horizon (and thus the light) is much dependent on altitude - mountaintops can be observed in sunlight while the rest of the terrain is still dark (a phenomenon known in German as [http://de.wikipedia.org/wiki/Alpenglühen Alpenglühen]). This is even more apparent when looking at high-altitude clouds. The following screenshots show the effect in Flightgear:

[[File:Alpine glow.jpg|400 px|While the valleys are still dark, the high mountain slopes already see the first direct sunlight]]
[[File:Predawn-cloud-glow.jpg|400px|Predawn high altitude cloud glow]]

Similarly, from high altitude the curvature of earth is apparent by the terrain (or haze in the direction towards the sun being more brightly illuminated than the terrain or haze away from the sun.

Short of directly computing the light passing through the atmosphere, these effects can be taken into account by using lightfields, i.e. by changing the color and intensity of the sunlight dependent on the position and altitude of the illuminated vertex. However, even computing parametrized lightfields make a significant performance impact as compared to the rendering situation at noon.

Unfortunately, the lightfield scheme used to render the light color combined with the scheme used to determine cloud shading is not guaranteed to give realistic effects. In reality for instance, a low sun can sometimes illuminate a layer from below. Whether this is possible or not depends on how far the layer extends - if it extends all the way to the horizon, it can never be illuminated from below, but if it terminates before, this is possible. It also depends on the terrain - there might be a chain of mountains far away which blocks the sun. In order to get the situation right, the weather system would have to be able to determine the cloud cover ~200 km away from the current position, but in Flightgear typically neither the terrain nor the weather at such distances is known.

Another effect which is currently not addressed adequately is the inter-cloud shading (clouds casting shadows on other clouds). Due to the layer structure of clouds, at noon this is usually not a big issue and only the self-shading of clouds is relevant, but for a low sun inter-cloud shading (and fog being shaded by clouds) is often very pronounced in reality.

Contrary to common misconceptions, the sky itself doesn't necessarily become red-orange for a low sun - a clear sky remains usually dark blue, changing to light blue. The elements visible during a sunrise are:

* Rayleigh scattering in the upper atmosphere, coloring the sky itself red if dust or aerosols are present (for instance after a volcano eruption or in a region with polluted air) - this is almost absent in clean air

* Mie scattering of red-orange Rayleigh light in the lower atmosphere - this specifically creates a red-golden halo around the rising sun and is absent when looking away from the sun

* Diffuse scattering of red-orange light in the ground haze fog - this contribution colors all directions almost equally, it can also be seen by a viewer facing away from the sun.

* Clouds being illuminated by red-orange light - high clouds are translucent and can be seen against the sun, lower dense clouds block the sunlight and appear dark against the sun, but bright looking away from the sun. Most spectacular sunset pictures show red-orange clouds glowing in front of a relatively dark clear sky.

The following screenshots of a very coloured sunrise in which successively the diffuse scattering and the Mie scattering components are removed illustrate this - in a clear, Rayleigh dominated sky the blue sky color essentially remains:

[[File:Sunrise all.jpg|300px|Diffuse, Mie and Rayleigh scattering]]
[[File:Sunrise mie rayleigh.jpg|300px|Mie and Rayleigh scattering]]
[[File:Sunrise rayleigh.jpg|300px|Rayleigh scattering only]]

The difference between diffuse and Mie scattering are more apparent when looking 90 degrees away from the sun. The diffuse component is unchanged, however the Mie component shows a dependence on view direction:

[[File:Sunrise side all.jpg|300px|Diffuse, Mie and Rayleigh scattering]]
[[File:Sunrise side mie.jpg|300px|Mie and Rayleigh scattering]]

== Predawn light scattering ==

Before sunrise, there is no direct light from the sun available, all light which reaches the ground has scattered at least once in the upper atmosphere (which is already illuminated). In the context of the [http://en.wikipedia.org/wiki/Phong_reflection_model Phong reflection model], this means that the diffuse and specular lighting is absent.

Since Rayleigh scattering dominates the upper atmosphere light scattering, predawn light is usually blue. However, this is not the whole story, as the perception of low intensity light is also biased towards blue (this is known as the [http://en.wikipedia.org/wiki/Purkinje_effect Purkinje effect] and the reason why moonlit scenes appear bluish in spite of the fact that moonlight is just reflected sunlight and has the same spectrum). The sudden change to the red direct light of the rising sun can create for a short time spectacular contrasts.

However, in the presence of a high cloud or haze layer, direct light can be diffuse scattered towards the ground. In this case, the ground predawn light is actually brighter than for a clear sky, and it has a red color. The following screenshots illustrate this in Flightgear:

[[File:Predawn-scatter1.jpg|400px|Usual predawn light]]
[[File:Predawn-scatter2.jpg|400px|Predawn light with high haze layer]]

== Light scattering on clouds ==

Despite being rendered technically in a completely different way from haze and fog (texture stacks vs. fog function in terrain shaders), the physics of light scattering on clouds is no different from the physics of light scattering in haze. Mie and diffuse scattering are the main mechanisms on water droplets. The thickness of the cloud makes all the difference here.

We have already discussed the mean effect of light attenuation on a cloud layer, let's look now at some specifics.

=== Mie scattering on thin clouds ===

When a thick cloud is before the sun, it absorbs the sunlight and the cloud appears dark, which is the effect of diffuse scattering. However, when a thin cloud is illuminated from behind, it glows brilliant white during the day or red-golden during sunrise. This is the effect of forward scattering - the light scattering is strong as long as the scattering angle is small and sun, cloud and eye are approximately lined up. As with haze, Mie scattering creates a bright halo in thin cloud cover.

At daytime, this creates a whiteout of a cloud when the sun is right behind it. If other, more dense clouds are also in the scene, this creates an impressive play of light and shadow:

[[File:Cloud_mie03.jpg|500px|center|Mie scattering during the day]]

Interestingly enough, cloud dominated by Mie scattering appear a relatively dark grey (as if they were in shadow) when seen from the side, even when they are fully illuminated. This is caused by the low probability of light scattered to large angles - since all light is focused forward, the side of the cloud becomes dark.

At sunrise and sunset, the effect of Mie scattering is even more prominent - since the direct sunlight coming through the upper atmosphere is red-golden due to the effect of Rayleigh scattering, the Mie-halo created by light scattering in the clouds is also coloured. Combined with diffuse shading on denser clouds, this generates very vivid colors which change quickly as the sun rises higher and both light intensity and hue change.

[[File:Cloud_mie01.jpg|400px|Mie scattering on thin clouds during sunrise]]
[[File:Cloud_mie02.jpg|400px|Mie scattering on thin clouds during sunrise, a bit later]]

Mie scattering is essentially absent whenever a cloud becomes opaque, i.e. when it is larger than the light attenuation length in the cloud.

== Latest version ==

The latest version of the project code is found in the [https://gitlab.com/flightgear/fgdata FGData master branch].

== Related content ==
* [[A local weather system]]
* [[Procedural Texturing]]
* [[ALS technical notes]]

== Further reading ==

* [http://www.science-and-fiction.org/rendering/als.html Atmospheric Light Scattering] (general overview and gallery)
* [http://www.science-and-fiction.org/rendering/aurora.html Aurora Borealis in ALS]

[[Category:Atmospheric light scattering shader]]

Cessna 172P

2026-07-02T22:21:04Z

Celesta: /* Features */

{{:{{PAGENAME}}/info}}
The '''Cessna 172P ''Skyhawk''''' is a four-seat, single-engine, high-wing fixed-wing [[aircraft]]. First flown in 1955 and still in production, more Cessna 172s have been built than any other aircraft.

The Cessna 172 has been the default aircraft in [[FlightGear]] since 2000, when it replaced the [[Navion]]. It has had a long development and includes a wide variety of simulation features. In 2015, it went through a complete refresh, including engine options, various tire sizes and floats, as well as a complete cockpit texture makeover. This new detailed version of the plane has become the default aircraft since FlightGear 3.6.

== Features ==

The new C172p has a much better 3D model and is now fully textured (including the interior). All the switches in the cockpit are clickable. It also has an improved FDM ([[Flight Dynamics Model]] - the "physics" of the plane), more complex procedures and new realistic checklists, new sound effects, and damage modelling. The aircraft can get damaged if mishandled (e.g. gear collapse after a hard landing).

[[File:c172p-preview5.jpg|center|700px]]

The aircraft currently has five variants, all available from the aircraft menu:
* regular wheels
* 26" bush tires
* 36" bush tires
* pontoons
* amphibious
* snow skis

Also, from the same menu, the user can select two different engines:
* 160 HP
* 180 HP (recommended when using pontoons, amphibian and skis variants)

The aircraft now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the modelling includes wheel collapse, wings breaking, etc. The damage can be turned off in the aircraft menu, which also contains an option for repairing the aircraft.

The windows now can get foggy or frosty, depending on the combination of interior and exterior temperatures. The pilot must then use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. Alternatively, it's possible to disable the effect in the "Aircraft Options" in the "Cessna 172P" menu. This effect depends on the [[ALS]] (Atmospheric Light Scattering) effects.

The FDM has also been modified. The aircraft may enter into a spin in case of an asymmetric [[stall]] (a particularly dangerous situation when turning to final, in which case the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as adding a new 180 HP engine.

There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]].

Also, if the user has enabled ALS ([[Atmospheric light scattering]]) in the Rendering Options, then it's possible to activate the flashlight by clicking on the "Cessna 172P" menu and selecting "Flashlight". Select it once for the white flashlight, select it again for a red one and select it one more time to turn it off.

The aircraft can now go through a pre-flight: wheel chocks, tie-downs and the pitot tube cover can now be added or removed, oil management and fuel contamination by water have been implemented (both of which are not activated by default, but are available in the Aircraft Options dialogue).

Carburettor icing is also modelled. Accumulating carburettor ice will result in loss of power. Applying carb heat will help to melt it. If the engine starts to cough when carb heat is applied, it means that ice has indeed been accumulated in the carburettor and now is being melted. To reduce a cough during the melting process, one can lean the mixture.

Static objects can be toggled in the Ground Equipment dialogue. These include cones under the wings, a fuel truck, a ground power unit and ladders. The ground power can be used to recharge the battery and the fuel truck can be used to refuelling the tanks. The walker can climb the ladder by walking towards it, which makes it easy to access the fuel tank cap in order to refill it.

[[File:c172p-panel-lighting.jpg|700px|center|thumb|Cessna 172P cockpit at night]]

== Handling The Aircraft ==
=== Pre-Flight Inspection ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P secured at Aosta Airport]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Fuel quantity: add by clicking on the fuel tank caps above each wing (you can add a ladder in the Ground Equipment dialog and climb it with the walker as well)
* Left wing: remove tie-down
* Left wing: remove pitot tube cover
* Left wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check for fuel contamination
* Nose: check for oil quantity by clicking on the oil door in the nose. Critical oil level for either engine is 5.0 quarts.
* Nose: remove wheel chocks

=== Engine Start (manual and complex startup) ===
[[File:c172p-panel-closeup.jpg|300px||thumb|Cessna 172P before starting the engine]]
* Priming: prime the engine at least 3 times
* Mixture: Rich (red lever all the way in)
* Throttle: Open 1/8 (black lever at 20%)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

=== Engine Start (automatically with Autostart) ===
* Click on the menu "Cessna C172P" and select "Autostart" in order to start the plane. Please note that the Autostart attempts to start the engine with the mixture full rich, so if you are taking off from a very high altitude airport you may need to manually start the plane.

=== Takeoff ===
[[File:c172p-preview0.jpg|300px||thumb|Cessna 172P ready for take off]]
* no flaps
* full throttle
* rotate at 55 KIAS

=== Climbout ===
* no flaps
* full throttle
* 75 KIAS

=== Cruise ===
* throttle 65%
* mixture rich of peak
* speed around 100 knots

=== Landing ===
[[File:c172p-preview4.jpg|300px||thumb|Cessna 172P about to touch down]]
* full flaps
* 60 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

The information in this section is based on external resources.<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! Airspeed !! CAS
|-
| Stall speed, landing configuration, VS0 || 46 - 48 kt
|-
| Stall speed, clean, VS1 || 51 - 53 kt
|-
| Rotation speed, VR || 55 kt
|-
| Best angle of climb speed, VX || 59 kt
|-
| Best rate of climb speed, VY || 76 kt
|-
| Maximum flap extended speed, VFE || 85 kt
|-
| rowspan="2" valign="top" | Maneuvering speed, VA || 96 kt (floatplane)
|-
| 99 kt (landplane)
|-
| Maximum structural cruising speed, VNO || 127 kt
|-
| Never exceed speed, VNE || 158 kt
|}

== FAQ ==
{{Main article|Cessna 172P/FAQ}}

== Development ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/Juanvvc/c172p-detailed repository], where a [https://github.com/Juanvvc/c172p-detailed/issues list of issues and future enhancements] can also be found.

== Gallery ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P high over Italy
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| Cessna 172P with equipment resting on volumetric grass
c172p-preview7.jpg|PT-IAO on a soft dirt runway
c172p-preview0.jpg|Panel view, about to take off
c172p-preview2.jpg|Parked and secured
c172p-preview13.jpg|Night lighting effects
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P resting on 2 types of volumetric grass
c172p-preview1.jpg|Float variant taking off
c172p-preview3.jpg|Ski variant over Freiburg
c172p-preview4.jpg|About to land at Aosta Airport
c172p-panel-closeup.jpg|Panel close-up
c172p-preview6.jpg|Hazy day over Naples
c172p-preview8.jpg|Sightseeing at Chapada Diamantina
c172p-preview9.jpg|Bush take off
c172p-preview12.jpg|Night flight with dimmed post lights
c172p-panel-lighting.jpg|Full post lighting
c172p-preview10.jpg|Amphibian variant at Hawaii
c172p-preview11.jpg|Bush variant
c172p-panel-landing.jpg|About to land
c172p-ground-objects.jpg|PT-IAO with ground objects
c172p-particles.jpg|Taking off on water, showing the particle system
c172p-parked.jpg|N35799 livery parked at Camden Airport (YSCN)
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
</gallery>

== External links ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[zh:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Cessna 172P

2026-07-02T22:15:40Z

Celesta: /* Features */

{{:{{PAGENAME}}/info}}
The '''Cessna 172P ''Skyhawk''''' is a four-seat, single-engine, high-wing fixed-wing [[aircraft]]. First flown in 1955 and still in production, more Cessna 172s have been built than any other aircraft.

The Cessna 172 has been the default aircraft in [[FlightGear]] since 2000, when it replaced the [[Navion]]. It has had a long development and includes a wide variety of simulation features. In 2015, it went through a complete refresh, including engine options, various tire sizes and floats, as well as a complete cockpit texture makeover. This new detailed version of the plane has become the default aircraft since FlightGear 3.6.

== Features ==

The new C172p has a much better 3D model and is now fully textured (including the interior). All the switches in the cockpit are clickable. It also has an improved FDM ([[Flight Dynamics Model]] - the "physics" of the plane), more complex procedures and new realistic checklists, new sound effects, and damage modelling. The aircraft can get damaged if mishandled (e.g. gear collapse after a hard landing).

[[File:c172p-preview5.jpg|center|700px]]

The aircraft currently has five variants, all available from the aircraft menu:
* regular wheels
* 26" bush tires
* 36" bush tires
* pontoons
* amphibious
* snow skis

Also, from the same menu, the user can select two different engines:
* 160 HP
* 180 HP (recommended when using pontoons, amphibian and skis variants)

The aircraft now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the modelling includes wheel collapse, wings breaking, etc. The damage can be turned off in the aircraft menu, which also contains an option for repairing the aircraft.

The windows now can get foggy or frosty, depending on the combination of interior and exterior temperatures. The pilot must then use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. Alternatively, it's possible to disable the effect in the "Aircraft Options" in the "Cessna 172P" menu. This effect depends on the ALS (Atmospheric Light Scattering) effects.

The FDM has also been modified. The aircraft may enter into a spin in case of an asymmetric [[stall]] (a particularly dangerous situation when turning to final, in which case the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as adding a new 180 HP engine.

There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]].

Also, if the user has enabled ALS ([[Atmospheric light scattering]]) in the Rendering Options, then it's possible to activate the flashlight by clicking on the "Cessna 172P" menu and selecting "Flashlight". Select it once for the white flashlight, select it again for a red one and select it one more time to turn it off.

The aircraft can now go through a pre-flight: wheel chocks, tie-downs and the pitot tube cover can now be added or removed, oil management and fuel contamination by water have been implemented (both of which are not activated by default, but are available in the Aircraft Options dialogue).

Carburettor icing is also modelled. Accumulating carburettor ice will result in loss of power. Applying carb heat will help to melt it. If the engine starts to cough when carb heat is applied, it means that ice has indeed been accumulated in the carburettor and now is being melted. To reduce a cough during the melting process, one can lean the mixture.

Static objects can be toggled in the Ground Equipment dialogue. These include cones under the wings, a fuel truck, a ground power unit and ladders. The ground power can be used to recharge the battery and the fuel truck can be used to refuelling the tanks. The walker can climb the ladder by walking towards it, which makes it easy to access the fuel tank cap in order to refill it.

[[File:c172p-panel-lighting.jpg|700px|center|thumb|Cessna 172P cockpit at night]]

== Handling The Aircraft ==
=== Pre-Flight Inspection ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P secured at Aosta Airport]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Fuel quantity: add by clicking on the fuel tank caps above each wing (you can add a ladder in the Ground Equipment dialog and climb it with the walker as well)
* Left wing: remove tie-down
* Left wing: remove pitot tube cover
* Left wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check for fuel contamination
* Nose: check for oil quantity by clicking on the oil door in the nose. Critical oil level for either engine is 5.0 quarts.
* Nose: remove wheel chocks

=== Engine Start (manual and complex startup) ===
[[File:c172p-panel-closeup.jpg|300px||thumb|Cessna 172P before starting the engine]]
* Priming: prime the engine at least 3 times
* Mixture: Rich (red lever all the way in)
* Throttle: Open 1/8 (black lever at 20%)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

=== Engine Start (automatically with Autostart) ===
* Click on the menu "Cessna C172P" and select "Autostart" in order to start the plane. Please note that the Autostart attempts to start the engine with the mixture full rich, so if you are taking off from a very high altitude airport you may need to manually start the plane.

=== Takeoff ===
[[File:c172p-preview0.jpg|300px||thumb|Cessna 172P ready for take off]]
* no flaps
* full throttle
* rotate at 55 KIAS

=== Climbout ===
* no flaps
* full throttle
* 75 KIAS

=== Cruise ===
* throttle 65%
* mixture rich of peak
* speed around 100 knots

=== Landing ===
[[File:c172p-preview4.jpg|300px||thumb|Cessna 172P about to touch down]]
* full flaps
* 60 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

The information in this section is based on external resources.<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! Airspeed !! CAS
|-
| Stall speed, landing configuration, VS0 || 46 - 48 kt
|-
| Stall speed, clean, VS1 || 51 - 53 kt
|-
| Rotation speed, VR || 55 kt
|-
| Best angle of climb speed, VX || 59 kt
|-
| Best rate of climb speed, VY || 76 kt
|-
| Maximum flap extended speed, VFE || 85 kt
|-
| rowspan="2" valign="top" | Maneuvering speed, VA || 96 kt (floatplane)
|-
| 99 kt (landplane)
|-
| Maximum structural cruising speed, VNO || 127 kt
|-
| Never exceed speed, VNE || 158 kt
|}

== FAQ ==
{{Main article|Cessna 172P/FAQ}}

== Development ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/Juanvvc/c172p-detailed repository], where a [https://github.com/Juanvvc/c172p-detailed/issues list of issues and future enhancements] can also be found.

== Gallery ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P high over Italy
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| Cessna 172P with equipment resting on volumetric grass
c172p-preview7.jpg|PT-IAO on a soft dirt runway
c172p-preview0.jpg|Panel view, about to take off
c172p-preview2.jpg|Parked and secured
c172p-preview13.jpg|Night lighting effects
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P resting on 2 types of volumetric grass
c172p-preview1.jpg|Float variant taking off
c172p-preview3.jpg|Ski variant over Freiburg
c172p-preview4.jpg|About to land at Aosta Airport
c172p-panel-closeup.jpg|Panel close-up
c172p-preview6.jpg|Hazy day over Naples
c172p-preview8.jpg|Sightseeing at Chapada Diamantina
c172p-preview9.jpg|Bush take off
c172p-preview12.jpg|Night flight with dimmed post lights
c172p-panel-lighting.jpg|Full post lighting
c172p-preview10.jpg|Amphibian variant at Hawaii
c172p-preview11.jpg|Bush variant
c172p-panel-landing.jpg|About to land
c172p-ground-objects.jpg|PT-IAO with ground objects
c172p-particles.jpg|Taking off on water, showing the particle system
c172p-parked.jpg|N35799 livery parked at Camden Airport (YSCN)
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
</gallery>

== External links ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[zh:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:15:12Z

Celesta: /* 速度 */

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆在20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（{{Key press|S}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 全油门
* 在55 KIAS时抬轮

=== 爬升 ===
* 不放襟翼
* 全油门
* 75 KIAS

=== 巡航 ===
* 油门65%
* 混合比富油峰值
* 速度约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 60 KIAS

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上型）
|-
| 99 kt（陆上型）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:13:37Z

Celesta:

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|thumb|夜间的c172p仪表盘]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P停放在Aosta机场]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|启动引擎前的Cessna 172P]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆在20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（{{Key press|S}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|准备起飞的Cessna 172P]]
* 不放襟翼
* 全油门
* 在55 KIAS时抬轮

=== 爬升 ===
* 不放襟翼
* 全油门
* 75 KIAS

=== 巡航 ===
* 油门65%
* 混合比富油峰值
* 速度约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|即将接地的Cessna 172P]]
* 全襟翼
* 60 KIAS

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上飞机）
|-
| 99 kt（陆上飞机）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Zh/Cessna 172P

2026-07-02T22:10:06Z

Celesta:

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
'''Cessna 172P ''Skyhawk''''' 是一款四座、单发、上单翼固定翼[[aircraft|飞机]]。它于1955年首飞，至今仍在生产，Cessna 172系列的产量超过任何其他飞机。

自2000年取代[[Navion]]以来，Cessna 172一直是[[FlightGear]]的默认飞机。它经历了长期的发展，并包含了多种模拟特性。2015年，这个机模经历了全面翻新，包括发动机选项、多种轮胎尺寸和浮筒，以及驾驶舱纹理的全面改进。自FlightGear 3.6之后，这个新的精细化版本成为默认飞机。

== 特性 ==

新的C172p拥有更好的3D模型，并且已完全纹理化（包括内部）。驾驶舱中的所有开关均可点击。它还改进了FDM（[[Flight Dynamics Model|飞行动力学模型]]——飞机的“物理”），更复杂的程序和新的真实检查单，新的音效，以及损伤建模。如果操作不当，飞机会受损（例如重着陆后起落架坍塌）。

[[File:c172p-preview5.jpg|center|700px]]

该飞机目前有五种改型，可从飞机菜单中选择：
* 常规机轮
* 26英寸越野轮胎
* 36英寸越野轮胎
* 浮筒
* 水陆两栖
* 雪地滑雪板

同样，在同一菜单中，用户可以选择两种不同的发动机：
* 160 HP
* 180 HP（使用浮筒、两栖和滑雪板改型时推荐）

飞机现在可能因碰撞、坠毁、重着陆或飞行中过载而受损，建模包括机轮坍塌、机翼断裂等。损伤可以在飞机菜单中关闭，该菜单还包含修复飞机的选项。

窗户现在可能会起雾或结霜，取决于内部和外部温度的组合。飞行员必须使用座舱加热和座舱空气操纵杆（襟翼右侧）来控制。或者，可以在“Cessna 172P”菜单的“Aircraft Options”中禁用该效果。此效果依赖于ALS（[[Atmospheric light scattering|大气光散射]]）效果。

FDM也经过了修改。飞机在不对称[[stall|失速]]时可能进入螺旋（这是一种特别危险的情况，尤其在转向五边时，此时飞机处于低速和低高度）。FDM还经过调整，包括在水上起飞或降落时的水动力效应，并增加了新的180 HP发动机。

有多种涂装可用，其中一些分辨率高于其他，在涂装菜单中标记为HD。每个HD涂装还具有独特的驾驶舱和内部纹理。

该飞机模拟了[[Bendix/King KAP140 Autopilot|Bendix/King KAP140自动驾驶仪]]。

此外，如果用户在渲染选项中启用了ALS（[[Atmospheric light scattering|大气光散射]]），则可以通过点击“Cessna 172P”菜单并选择“Flashlight”来激活手电筒。选择一次为白色手电筒，再选一次为红色，再选一次关闭。

飞机现在可以进行飞行前检查：轮挡、系留绳和空速管套现在可以添加或移除，机油管理和燃油水分污染已实现（两者默认未激活，但可在Aircraft Options对话框中启用）。

化油器结冰也进行了建模（模拟）。累积的化油器冰会导致发动机功率下降。开启化油器加热（carb heat）有助于融化积冰。如果在开启化油器加热时发动机开始“咳嗽”（运转不稳），这说明化油器内确实已经累积了冰，且现在正在融化。为了减少融化过程中的“咳嗽”现象，可以调稀混合气（lean the mixture）。

地面设备对话框中可以切换静态物体。这些包括机翼下的锥桶、加油车、地面电源装置和梯子。地面电源可用于给电池充电，加油车可用于给油箱加油。Walker可以走近梯子爬上梯子，从而接近油箱盖以加油。

[[File:c172p-panel-lighting.jpg|700px|center|Cessna 172P cockpit at night]]

== 飞机操纵 ==
=== 飞行前检查 ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P secured at Aosta Airport]]
建议使用任何外部视角或激活Walker来进行这些程序。
* 燃油量：点击每个机翼上方的油箱盖添加燃油（您可以在Ground Equipment对话框中添加梯子，并用Walker爬上去）
* 左翼：移除系留绳
* 左翼：移除空速管套
* 左翼：点击机翼下方检查燃油污染并取燃油样本。如果样本呈淡蓝色，则燃油未受污染，可以倒回油箱。如果样本透明或部分透明，您必须丢弃它并取新样本，直到完全淡蓝色为止
* 尾部：移除系留绳
* 右翼：移除系留绳
* 右翼：检查燃油污染
* 机头：点击机头机油门检查机油量。两种发动机的临界油位均为5.0夸脱。
* 机头：移除轮挡

=== 发动机启动（复杂的手动启动） ===
[[File:c172p-panel-closeup.jpg|300px||thumb|Cessna 172P before starting the engine]]
* 注油：至少注油3次
* 混合比：富油（红色操纵杆完全推入）
* 油门：开启1/8（黑色操纵杆在20%）
* 停机刹车：启用（{{Key press|Shift|B}}）
* 螺旋桨区域：清空
* 主开关：ON（两者）
* 磁电机：两者（按{{Key press|<nowiki>}</nowiki>}}三次）
* 点火：启动（{{Key press|S}}）

=== 发动机启动（使用Autostart） ===
* 点击菜单“Cessna C172P”并选择“Autostart”以自动启动飞机。请注意，Autostart尝试以混合比全富油启动发动机，因此如果您从高海拔机场起飞，可能需要手动启动飞机。

=== 起飞 ===
[[File:c172p-preview0.jpg|300px||thumb|Cessna 172P ready for take off]]
* 不放襟翼
* 全油门
* 在55 KIAS时抬轮

=== 爬升 ===
* 不放襟翼
* 全油门
* 75 KIAS

=== 巡航 ===
* 油门65%
* 混合比富油峰值
* 速度约100节

=== 着陆 ===
[[File:c172p-preview4.jpg|300px||thumb|Cessna 172P about to touch down]]
* 全襟翼
* 60 KIAS

=== 速度 ===
: ''另见 [[Aircraft speed#V speeds]]''

本节信息基于外部资料。<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! 空速 !! CAS
|-
| 失速速度，着陆构型，VS0 || 46 - 48 kt
|-
| 失速速度，光洁构型，VS1 || 51 - 53 kt
|-
| 抬轮速度，VR || 55 kt
|-
| 最佳爬升角速度，VX || 59 kt
|-
| 最佳爬升率速度，VY || 76 kt
|-
| 最大襟翼伸出速度，VFE || 85 kt
|-
| rowspan="2" valign="top" | 机动速度，VA || 96 kt（水上飞机）
|-
| 99 kt（陆上飞机）
|-
| 最大结构巡航速度，VNO || 127 kt
|-
| 永不超过速度，VNE || 158 kt
|}

== 常见问题 ==
主条目：[[Cessna 172P/FAQ]]

== 开发 ==

该飞机正在持续开发中，可以在其[https://github.com/Juanvvc/c172p-detailed 代码仓库]中跟进，其中还包含[https://github.com/Juanvvc/c172p-detailed/issues 问题和增强列表]。

== 图库 ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P 飞越意大利高空
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| C172P 和地面设备停放在草坪上
c172p-preview7.jpg|PT-IAO 在松软土质跑道上
c172p-preview0.jpg|驾驶舱视角，准备起飞
c172p-preview2.jpg|停放并固定
c172p-preview13.jpg|夜间照明效果
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P 停放在两种草坪上
c172p-preview1.jpg|浮筒型起飞
c172p-preview3.jpg|滑雪板型飞越弗赖堡
c172p-preview4.jpg|即将在奥斯塔机场着陆
c172p-panel-closeup.jpg|驾驶舱面板特写
c172p-preview6.jpg|那不勒斯上空薄雾天
c172p-preview8.jpg|在沙帕达迪亚曼蒂纳观光
c172p-preview9.jpg|越野起飞
c172p-preview12.jpg|夜航，调暗的仪表灯
c172p-panel-lighting.jpg|全亮的仪表灯
c172p-preview10.jpg|在夏威夷的两栖型
c172p-preview11.jpg|越野型
c172p-panel-landing.jpg|即将着陆
c172p-ground-objects.jpg|PT-IAO 和地面设备
c172p-particles.jpg|水上起飞，显示粒子系统
c172p-parked.jpg|N35799 涂装停放在卡姆登机场（YSCN）
c172p-damage.jpg|重着陆导致起落架坍塌
c172p-frost.jpg|满足条件时，窗户上会出现霜或雾
</gallery>

== 外部链接 ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Cessna 172P

2026-07-02T21:37:27Z

Celesta:

{{:{{PAGENAME}}/info}}
The '''Cessna 172P ''Skyhawk''''' is a four-seat, single-engine, high-wing fixed-wing [[aircraft]]. First flown in 1955 and still in production, more Cessna 172s have been built than any other aircraft.

The Cessna 172 has been the default aircraft in [[FlightGear]] since 2000, when it replaced the [[Navion]]. It has had a long development and includes a wide variety of simulation features. In 2015, it went through a complete refresh, including engine options, various tire sizes and floats, as well as a complete cockpit texture makeover. This new detailed version of the plane has become the default aircraft since FlightGear 3.6.

== Features ==

The new C172p has a much better 3D model and is now fully textured (including the interior). All the switches in the cockpit are clickable. It also has an improved FDM ([[Flight Dynamics Model]] - the "physics" of the plane), more complex procedures and new realistic checklists, new sound effects, and damage modelling. The aircraft can get damaged if mishandled (e.g. gear collapse after a hard landing).

[[File:c172p-preview5.jpg|center|700px]]

The aircraft currently has five variants, all available from the aircraft menu:
* regular wheels
* 26" bush tires
* 36" bush tires
* pontoons
* amphibious
* snow skis

Also, from the same menu, the user can select two different engines:
* 160 HP
* 180 HP (recommended when using pontoons, amphibian and skis variants)

The aircraft now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the modelling includes wheel collapse, wings breaking, etc. The damage can be turned off in the aircraft menu, which also contains an option for repairing the aircraft.

The windows now can get foggy or frosty, depending on the combination of interior and exterior temperatures. The pilot must then use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. Alternatively, it's possible to disable the effect in the "Aircraft Options" in the "Cessna 172P" menu. This effect depends on the ALS (Atmospheric Light Scattering) effects.

The FDM has also been modified. The aircraft may enter into a spin in case of an asymmetric [[stall]] (a particularly dangerous situation when turning to final, in which case the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as adding a new 180 HP engine.

There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]].

Also, if the user has enabled ALS ([[Atmospheric light scattering]]) in the Rendering Options, then it's possible to activate the flashlight by clicking on the "Cessna 172P" menu and selecting "Flashlight". Select it once for the white flashlight, select it again for a red one and select it one more time to turn it off.

The aircraft can now go through a pre-flight: wheel chocks, tie-downs and the pitot tube cover can now be added or removed, oil management and fuel contamination by water have been implemented (both of which are not activated by default, but are available in the Aircraft Options dialogue).

Carburettor icing is also modelled. Accumulating carburettor ice will result in loss of power. Applying carb heat will help to melt it. If the engine starts to cough when carb heat is applied, it means that ice has indeed been accumulated in the carburettor and now is being melted. To reduce a cough during the melting process, one can lean the mixture.

Static objects can be toggled in the Ground Equipment dialogue. These include cones under the wings, a fuel truck, a ground power unit and ladders. The ground power can be used to recharge the battery and the fuel truck can be used to refuelling the tanks. The walker can climb the ladder by walking towards it, which makes it easy to access the fuel tank cap in order to refill it.

[[File:c172p-panel-lighting.jpg|700px|center|Cessna 172P cockpit at night]]

== Handling The Aircraft ==
=== Pre-Flight Inspection ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P secured at Aosta Airport]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Fuel quantity: add by clicking on the fuel tank caps above each wing (you can add a ladder in the Ground Equipment dialog and climb it with the walker as well)
* Left wing: remove tie-down
* Left wing: remove pitot tube cover
* Left wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check for fuel contamination
* Nose: check for oil quantity by clicking on the oil door in the nose. Critical oil level for either engine is 5.0 quarts.
* Nose: remove wheel chocks

=== Engine Start (manual and complex startup) ===
[[File:c172p-panel-closeup.jpg|300px||thumb|Cessna 172P before starting the engine]]
* Priming: prime the engine at least 3 times
* Mixture: Rich (red lever all the way in)
* Throttle: Open 1/8 (black lever at 20%)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

=== Engine Start (automatically with Autostart) ===
* Click on the menu "Cessna C172P" and select "Autostart" in order to start the plane. Please note that the Autostart attempts to start the engine with the mixture full rich, so if you are taking off from a very high altitude airport you may need to manually start the plane.

=== Takeoff ===
[[File:c172p-preview0.jpg|300px||thumb|Cessna 172P ready for take off]]
* no flaps
* full throttle
* rotate at 55 KIAS

=== Climbout ===
* no flaps
* full throttle
* 75 KIAS

=== Cruise ===
* throttle 65%
* mixture rich of peak
* speed around 100 knots

=== Landing ===
[[File:c172p-preview4.jpg|300px||thumb|Cessna 172P about to touch down]]
* full flaps
* 60 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

The information in this section is based on external resources.<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! Airspeed !! CAS
|-
| Stall speed, landing configuration, VS0 || 46 - 48 kt
|-
| Stall speed, clean, VS1 || 51 - 53 kt
|-
| Rotation speed, VR || 55 kt
|-
| Best angle of climb speed, VX || 59 kt
|-
| Best rate of climb speed, VY || 76 kt
|-
| Maximum flap extended speed, VFE || 85 kt
|-
| rowspan="2" valign="top" | Maneuvering speed, VA || 96 kt (floatplane)
|-
| 99 kt (landplane)
|-
| Maximum structural cruising speed, VNO || 127 kt
|-
| Never exceed speed, VNE || 158 kt
|}

== FAQ ==
{{Main article|Cessna 172P/FAQ}}

== Development ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/Juanvvc/c172p-detailed repository], where a [https://github.com/Juanvvc/c172p-detailed/issues list of issues and future enhancements] can also be found.

== Gallery ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P high over Italy
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| Cessna 172P with equipment resting on volumetric grass
c172p-preview7.jpg|PT-IAO on a soft dirt runway
c172p-preview0.jpg|Panel view, about to take off
c172p-preview2.jpg|Parked and secured
c172p-preview13.jpg|Night lighting effects
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P resting on 2 types of volumetric grass
c172p-preview1.jpg|Float variant taking off
c172p-preview3.jpg|Ski variant over Freiburg
c172p-preview4.jpg|About to land at Aosta Airport
c172p-panel-closeup.jpg|Panel close-up
c172p-preview6.jpg|Hazy day over Naples
c172p-preview8.jpg|Sightseeing at Chapada Diamantina
c172p-preview9.jpg|Bush take off
c172p-preview12.jpg|Night flight with dimmed post lights
c172p-panel-lighting.jpg|Full post lighting
c172p-preview10.jpg|Amphibian variant at Hawaii
c172p-preview11.jpg|Bush variant
c172p-panel-landing.jpg|About to land
c172p-ground-objects.jpg|PT-IAO with ground objects
c172p-particles.jpg|Taking off on water, showing the particle system
c172p-parked.jpg|N35799 livery parked at Camden Airport (YSCN)
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
</gallery>

== External links ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[zh:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Cessna 182S

2026-07-02T21:36:03Z

Celesta: /* Features */

{{:{{PAGENAME}}/info}}

The '''Cessna 182S Skylane''' is an American four-seat, single-engine, light [[Aircraft|airplane]], built by [[Cessna]] between 1996 and 2001. It uses a fuel-injected Textron Lycoming IO-540 AB1A5 with 230 HP at 2,400 RPM.

== Features ==
The Cessna 182S is one of the high-quality aircraft models in FlightGear.

The new Cessna 182S has a very detailed 3D model and a cockpit with highly detailed textures. Most of the switches in the cockpit are already clickable and working. It has a very realistic FDM based on real aerodynamic coefficients and the pilot operating handbook; engine power, EGT and fuel performance are tuned according the pilot operating handbook, the weight and balance behaves like written in the POH. Fly by the book - a link to real POH is given at the end of this page.

[[File:c182-panel-detail.jpg|center|800px]]

There are currently several liveries available: default Cessna livery, Blank, D-ELFP, HB-CZV, N182PJ, N321HW and some Custom registration Liveries.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]]. The cockpit can be illuminated at night by using the glareshield lighting, pedestal lighting and instruments/ radio lighting, controlled by two knobs. Dome lights which illuminates the cabin in a realistic way are in work. The knobs have two modes each, which can be used by clicking and dragging horizontally or vertically.

Also, if the user has enabled ALS (Atmospheric light scattering) in the Rendering Options, some effects are activated such as cockpit shadows, visible landing lights from the cockpit and rain effect on the windshield.

The Cessna 182S comes with static objects which can be activated via the Ground Equipment dialog in the aircraft menu. These include a fuel tank trailer, ladders to access the fuel caps (and which the walker can climb, ground power unit and a Dragon Engine Pre-Heater. Security cones are also available. Special Feature: The ground equipment will stay on ground where placed, independent from the movement of the aircraft! The aircraft can also go through a pre-flight check: wheel chocks, tie-downs and the pitot tube cover can now be added or removed.

[[File:c182-objects.jpg|600px|center|Cessna 182S with static elements]]

==Feature List==
For details and usage hints, please also read the [https://github.com/HHS81/c182s/blob/master/Documentation.md documentation].
*accurate flight model based on real test aerodynamic coefficients and POH
* accurate fuel flow numbers, engine power, airspeed and climbrate in nearly all pressure altitudes and temperatures with less than 5% difference from POH
* realistic [[stall]] behavior
* calculation of real KIAS based on KCAS, based on POH
* accurate weight and balance behavior

* New Start-up States: aircraft can be initialized in cruise, landing, takeoff and more states
* autostart for beginners

* fully simulated fuel system: fuel flow by gravity, engine pump and fuel pump simulated for each of the two tanks,; engine needs correct priming procedure according POH, fuel contamination simulated
* realistic electrical system, battery charge state depending on temperature, working circuit breakers
* fully simulated oil management (temperature, ....)
* simulation of cabin heat and defrost
* simulation of icing to wings, propellers and engines in icing conditions
* detailed damage and failure simulation

* High quality 3d-model, textures and animations
* Realistic exterior reflection shaders with fresnel effect and normalmap
* selectable chromed spinner and wheel fairings
* Very detailed 3d-interior
* moveable sun-visors
* all cockpit switches are working
* fully working audio panel
* fully simulated [[Bendix/King_KAP140_Autopilot]]
* fully simulated [[Davtron M803]] digital clock
* fully simulated Bendix King avionics stack (two [[Kx165|KX-165 VHF COM/NAV radios]], [[Bendix_King_KN62A_DME|KN-62A DME]], [[Bendix_King_KT_76A|KT-67C Transponder]], [[Bendix_King_KR_87_ADF_Receiver|KR-87 ADF]])
* Realistic interior light effects in ALS-Renderer
* Interior shadows in ALS-Renderer
* interior glass frost and fog effects in ALS-Renderer
* Exterior 3d-shadow in ALS-Renderer
* selectable and fully simulated Winterization kit
* External equipement like ladders, safety cones, tie ups, pitot cover, wheel chocks, external power source, simulated external engine pre-heater with sound - they keep their position on ground!
* aircraft can be preflight checked outside (free movement check of flight control surfaces; oil, fuel, pitot heat, ....)
* Walker - can be used to follow the Checklist outside
* [[Howto:Implement_Towbar|Towbar]] connecting to the nosewheel for ground handling
* Save states: aircraft remembers last switch, systems and configuration state
* Many liveries

=== Aerotowing gliders ===
The C182S and C182T are capable of [[Howto: Do aerotow over the net|aerotowing over multiplayer]] by the glider pilot pressing {{key press|Ctrl|o}} while behind the Cessna.
The Cessna pilot can release the hook anytime by pressing {{key press|Shift|O}}.

=== Dual control ===
The plane supports [[Dual control]] where a copilot can ride along in another multiplayer plane. The copilot needs to start the C182 copilot variant and then select the pilots plane from the multiplayer dialog. The pilot also need to select the copilot this way.

Currently the copilot is view-only and cannot take over controls.

=== Parachuters ===
Via the aircraft options menu you can remove the right cabin door and seats, to haul parachuters. When clicking on your passengers, they will climb out to the strut and jump off. The parachuters are even visible to other multiplayer aircraft (for that to work they need the C182s/t model installed).

To enable the Jump button (making it no longer grayed out), you need to first click the "Configure Humans" button to add a crew member, and climb above 150m (approx. 500ft).

=== Extended failures / surprise mode ===
The plane features a very detailed failure simulation and optionally can surprise you on the fly (if you wish, without notifying you). The failures dialog can be accessed by the aircraft menu, but you can also configure this for startup in your launcher by adding configuration options there. Please see [https://github.com/HHS81/c182s/blob/master/Documentation.md#extended-failure-simulation the documentation] for details.

== Handling The Aircraft (beginner version)==
You can activate more realistic handling at any time in the aircraft dialog, like fuel contamination, engine oil management and priming needs.

The full checklists are available ingame in the checklists dialog.

=== Pre-Flight Inspection ===
[[File:C182-ready-for-take-off.jpg|270px||thumb|Cessna 182S ready for take off]]
It's recommended to use any exterior view or activate the walker for these procedures.

* Cockpit: remove wind gust lock
* Check fuel quantity on both tanks (click on the red caps top of the wings)
* Left wing: remove pitot tube cover
* Left wing: remove tie-down
* Left wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Left main wheel: remove chocks
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check water contamination
* Right main wheel: remove chocks
* Right nose: check water contamination of fuel selector (below plane) and fuel strainer (right nose)
* Nose: remove wheel chocks
* Nose: check oil level (more than 6.0 quarts)
* Nose: remove chocks

=== Engine Start (manual and complex startup) ===
* Mixture: Idle cut-off (red lever full out)
* Propeller: High RPM (blue lever full in)
* Throttle: Open 1/4 inch (black lever ~5%-8% setting inSim)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Auxiliary Fuel Pump Switch: ON
* Advance mixture to full rich, keep it 3-5sec
* Then Idle Cutoff
* Auxiliary Fuel Pump Switch: Off
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: crank engine ({{Key press|S}} until engine fires)

If the engine was warm already, it usually starts without priming by just setting Mixture to rich and cranking.

If engine floods, then set mixture to idle cut off and throttle to 1/2 to full open and crank. When engine fires, set mixture to full rich and throttle to idle.

=== Takeoff ===
* no flaps or flaps 10deg
* cowl flaps open ({{Key press|Shift|F}} several times)
* full throttle
* rotate at 50-60 KIAS

=== Climbout ===
* no flaps
* cowl flaps open
* full throttle
* 80 KIAS
* Reduce power to stay in the green arcs as soon as obstacles are clear
** Fuel flow: max 15Gph
** Throttle: max 23 in.Hg

=== Cruise ===
[[File:c182-default.jpg|270px||thumb|Cessna 182S in the air]]
* 2000-2400 RPM
* 18-23 mp
* mixture rich of peak as recommended lean mixture setting for cruise or 125°F rich for best power
* speed between 120-140 knots depending on the power settings
* cowl flaps closed ({{Key press|f}} as appropriate -> watch CHT gauge)

=== Landing ===
* flaps 20deg or full flaps
* 60-70 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

{| class="wikitable"
! Airspeed !! IAS
|-
| Stall speed, landing configuration, VS0 || 36 kt
|-
| Stall speed, clean, VS1 || 43 kt
|-
| Rotation speed, VR || 55 kt
|-
| Best angle of climb speed, VX || 63 kt
|-
| Best rate of climb speed, VY || 80 kt
|-
| Maximum flap extended speed, VFE || 100 kt
|-
| Manoeuvring speed, VA || 110 kt
|-
| Maximum structural cruising speed, VNO || 140 kt
|-
| Never exceed speed, VNE || 175 kt
|-
| Max. Crosswind at landing || 15 kt
|}

=== Performance ===

{| class="wikitable"
|Cruise, 80% power, 6,000 ft || 140 kt
|-
|Cruise, 65% power, 8,000 ft || 130 kt
|-
|Cruise, 55% power, 10,000 ft || 121 kt
|}

{| class="wikitable"
|Range, 75% power, 6,000 ft || 820 nm
|-
|Range, 65% power, 8,000 ft || 910 nm
|-
|Range, 55% power, 10,000 ft || 968 nm
|}

{| class="wikitable"
|Best Climb<ref>POH 5-19; with 3100lbs, sea level, 2400 RPM, Full Throttle, mixture set to Maximum power Fuel Flow placard, Cowl Flaps Open, Std. Temperature</ref> || 924fpm
|-
|Service Ceiling || 18,100ft
|-
|Takeoff ground roll: 795ft (242m) over 50ft obstacle || 1,514ft
|-
|Landing ground roll: 590ft (180m) over 50ft obstacle || 1,390ft
|}

[[File:c182-cockpit-at-night.jpg|600px|center|Cessna 182S panel illumination]]

== FAQ ==
Main article: [[Cessna 182S/FAQ]]

== Versions ==

=== Stable release ===
The Last official release for your matching FlightGear version can be downloaded from the Launcher (FGAddon default Hangar).
There you can also easily update the plane, once updates get published.

Alternatively, GIT releases (and changelogs between versions) are here: https://github.com/HHS81/c182s/releases

These releases are usually also synced to FGAddons trunk hangar (used by fgfs next, which gets stable together with the next fgfs release and can be updated to from the launcher)

=== Development status/Issues/TODO ===

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/HHS81/c182s repository], where a [https://github.com/HHS81/c182s/issues list of issues and future enhancements] can also be found. Worth a visit!

* '''Damaged Gear in Multiplayer''': The damage model was updated recently (5/2021 for 2020.4.0) to also simulate gear collapse. Older versions (2020.3 and before) do not simulate this and thus do not transmit the necessary MP packets. This makes the "gear-OK" Property constantly showing a damage gear, if you use a newer model. The solution is that the pilot using the version showing the "crippled" gear to update his flightgear and plane to the latest FGAddon version OR use the [https://github.com/HHS81/c182s/releases/tag/version-1.4 GitHub release 1.4].

=== Using the latest development/git version ===
{{note|This may not work properly with the current stable (and older) flightgear versions. Development ''usually'' targets the latest flightgear stable, but may use also fresh features of flightgears "next" version.}}

If you want to use the latest github versions, they can be obtained here (<code>master</code>-branch): https://github.com/HHS81/c182s/archive/refs/heads/master.zip

* Make a new "Aircraft" folder (in case you don't already have one). Then add that directory to your launchers "Addons" tab as aircraft folder.
* Download a zipped version you want to use (links below).
* Extract the zipfile into your "Aircraft" folder.
* Rename the extracted <code>c182s-<version></code> folder to <code>c182s</code>.

== Gallery ==
{{screenshot cat
| category = Cessna 182S screenshots
| subject = the Cessna 182S
| image = C182-default.jpg
}}{{-}}
<gallery mode="packed">
GXLTGAltenrhein.jpg|aircraft sitting on the apron of St. Gallen-Altenrhein/ Switzerland
Cessna182S compositor2.jpg|aircraft sitting in the dark, all lights on
c182s.jpg|Cessna 182S at dusk
c182-cockpit-view.jpg|Default cockpit view
c182-external2.jpg|HB-CZV livery
c182-external3.jpg|D-ELFP livery
c182-external5.jpg|Cessna 182S over California
c182-external6.jpg|Another view of the HB-CZV livery
C182-4.jpg|Taking off
c182-rosskopf-at-dusk.jpg|Cessna 182S around Roßkopf in Freiburg/ Germany
C182STakeOff.jpg|Cessna 182S with custom registration at Siegerland Airport/ Germany
C182s-LandingPicture.jpg|C182s landing, showing the needed high pitch attitude
C182SDavtron803.jpg|The Davtron 803 clock in action
C182SWinterKit.jpg|Winterkit installed, and preheating the engine with an Engine Preheater
C182SFuelManagement.jpg|Fuel Management Dialog
c182-rain.jpg|Rain effect in the windshield
C182-oil-cap.png|Oil cap location
C182SOilManagement.jpg|Oil Management Dialog
C182-fuelports.png|Fuel selector and strainer quick drain valves location
c182-night-take-off.jpg|Ready to take off at night
c182-3.jpg|D-ELFP at dusk
C182SPitot.jpg|Pitot, Cover and message
C182SFreeMovementCheck.jpg|Checking the aileron
C182SCustomRegistration.jpg|The custom registration
c182-external4.jpg|N182PJ livery
c182-external-at-night.jpg|Default livery at night
c182-external1.jpg|N321HW livery
C182Scrashed.jpg|aircraft crashed
AboveSouthGermany.jpg|aircraft flying above South Germany
Cessna182S compositor.jpg|aircraft sitting in the dark, all lights on

</gallery>

== External links ==
* {{Wikipedia|Cessna 182 Skylane|lang=en}}
* [http://www.freechecklists.net/Resources/Cessna/182S+Skylane/ Links to Cessna 182S Checklists and W&B sheet]
* [http://tssflyingclub.org/documents/C182S_POH.pdf Cessna 182S POH]
* [https://www.aopa.org/go-fly/aircraft-and-ownership/aircraft-fact-sheets/cessna-182 Cessna 182S Aircraft Information Booklet]
* [http://www.jberaeroclub.com/uploads/1/7/4/0/17405139/c182maneuversguiderev2.pdf C182 Standardized flight maneuvers guide]
* [https://airplaneacademy.com/9-actionable-cessna-182-landing-tips-you-can-implement-today/ 9 Actionable Cessna 182 Landing Tips You Can Implement Today]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]
[[Category:Red Griffin ATC compatible aircraft]]

[[de:Cessna 182S]]

Cessna 172P

2026-07-02T21:32:46Z

Celesta: /* Features */

{{:{{PAGENAME}}/info}}
The '''Cessna 172P ''Skyhawk''''' is a four-seat, single-engine, high-wing fixed-wing [[aircraft]]. First flown in 1955 and still in production, more Cessna 172s have been built than any other aircraft.

The Cessna 172 has been the default aircraft in [[FlightGear]] since 2000, when it replaced the [[Navion]]. It has had a long development and includes a wide variety of simulation features. In 2015, it went through a complete refresh, including engine options, various tire sizes and floats, as well as a complete cockpit texture makeover. This new detailed version of the plane has become the default aircraft since [[Changelog_3.6|FlightGear 3.6]].

== Features ==

The new C172p has a much better 3D model and is now fully textured (including the interior). All the switches in the cockpit are clickable. It also has an improved FDM ([[Flight Dynamics Model]] - the "physics" of the plane), more complex procedures and new realistic checklists, new sound effects, and damage modelling. The aircraft can get damaged if mishandled (e.g. gear collapse after a hard landing).

[[File:c172p-preview5.jpg|center|700px]]

The aircraft currently has five variants, all available from the aircraft menu:
* regular wheels
* 26" bush tires
* 36" bush tires
* pontoons
* amphibious
* snow skis

Also, from the same menu, the user can select two different engines:
* 160 HP
* 180 HP (recommended when using pontoons, amphibian and skis variants)

The aircraft now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the modelling includes wheel collapse, wings breaking, etc. The damage can be turned off in the aircraft menu, which also contains an option for repairing the aircraft.

The windows now can get foggy or frosty, depending on the combination of interior and exterior temperatures. The pilot must then use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. Alternatively, it's possible to disable the effect in the "Aircraft Options" in the "Cessna 172P" menu. This effect depends on the ALS (Atmospheric Light Scattering) effects.

The FDM has also been modified. The aircraft may enter into a spin in case of an asymmetric [[stall]] (a particularly dangerous situation when turning to final, in which case the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as adding a new 180 HP engine.

There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]].

Also, if the user has enabled ALS ([[Atmospheric light scattering]]) in the Rendering Options, then it's possible to activate the flashlight by clicking on the "Cessna 172P" menu and selecting "Flashlight". Select it once for the white flashlight, select it again for a red one and select it one more time to turn it off.

The aircraft can now go through a pre-flight: wheel chocks, tie-downs and the pitot tube cover can now be added or removed, oil management and fuel contamination by water have been implemented (both of which are not activated by default, but are available in the Aircraft Options dialogue).

Carburettor icing is also modelled. Accumulating carburettor ice will result in loss of power. Applying carb heat will help to melt it. If the engine starts to cough when carb heat is applied, it means that ice has indeed been accumulated in the carburettor and now is being melted. To reduce a cough during the melting process, one can lean the mixture.

Static objects can be toggled in the Ground Equipment dialogue. These include cones under the wings, a fuel truck, a ground power unit and ladders. The ground power can be used to recharge the battery and the fuel truck can be used to refuelling the tanks. The walker can climb the ladder by walking towards it, which makes it easy to access the fuel tank cap in order to refill it.

[[File:c172p-panel-lighting.jpg|700px|center|Cessna 172P cockpit at night]]

== Handling The Aircraft ==
=== Pre-Flight Inspection ===
[[File:c172p-ground-objects.jpg|300px||thumb|Cessna 172P secured at Aosta Airport]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Fuel quantity: add by clicking on the fuel tank caps above each wing (you can add a ladder in the Ground Equipment dialog and climb it with the walker as well)
* Left wing: remove tie-down
* Left wing: remove pitot tube cover
* Left wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check for fuel contamination
* Nose: check for oil quantity by clicking on the oil door in the nose. Critical oil level for either engine is 5.0 quarts.
* Nose: remove wheel chocks

=== Engine Start (manual and complex startup) ===
[[File:c172p-panel-closeup.jpg|300px||thumb|Cessna 172P before starting the engine]]
* Priming: prime the engine at least 3 times
* Mixture: Rich (red lever all the way in)
* Throttle: Open 1/8 (black lever at 20%)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

=== Engine Start (automatically with Autostart) ===
* Click on the menu "Cessna C172P" and select "Autostart" in order to start the plane. Please note that the Autostart attempts to start the engine with the mixture full rich, so if you are taking off from a very high altitude airport you may need to manually start the plane.

=== Takeoff ===
[[File:c172p-preview0.jpg|300px||thumb|Cessna 172P ready for take off]]
* no flaps
* full throttle
* rotate at 55 KIAS

=== Climbout ===
* no flaps
* full throttle
* 75 KIAS

=== Cruise ===
* throttle 65%
* mixture rich of peak
* speed around 100 knots

=== Landing ===
[[File:c172p-preview4.jpg|300px||thumb|Cessna 172P about to touch down]]
* full flaps
* 60 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

The information in this section is based on external resources.<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

[[File:172P 01.jpg|300px]]
{| class="wikitable"
! Airspeed !! CAS
|-
| Stall speed, landing configuration, VS0 || 46 - 48 kt
|-
| Stall speed, clean, VS1 || 51 - 53 kt
|-
| Rotation speed, VR || 55 kt
|-
| Best angle of climb speed, VX || 59 kt
|-
| Best rate of climb speed, VY || 76 kt
|-
| Maximum flap extended speed, VFE || 85 kt
|-
| rowspan="2" valign="top" | Maneuvering speed, VA || 96 kt (floatplane)
|-
| 99 kt (landplane)
|-
| Maximum structural cruising speed, VNO || 127 kt
|-
| Never exceed speed, VNE || 158 kt
|}

== FAQ ==
{{Main article|Cessna 172P/FAQ}}

== Development ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/Juanvvc/c172p-detailed repository], where a [https://github.com/Juanvvc/c172p-detailed/issues list of issues and future enhancements] can also be found.

== Gallery ==
{{screenshot cat
| category = Cessna 172 screenshots
| subject = the Cessna 172
| image = Cessna 172P.jpg
}}{{-}}
<gallery mode="packed">
c172p-preview5.jpg|Cessna 172P high over Italy
C172P_and_equipment_on_Volumetric_grass_at_Innsbruck,_Austria_(Flightgear_2019.x).jpg| Cessna 172P with equipment resting on volumetric grass
c172p-preview7.jpg|PT-IAO on a soft dirt runway
c172p-preview0.jpg|Panel view, about to take off
c172p-preview2.jpg|Parked and secured
c172p-preview13.jpg|Night lighting effects
C172P_resting_on_Volumetric_grass_at_Innsbruck_Airport_-_Flightgear_2018.x.jpg| C172P resting on 2 types of volumetric grass
c172p-preview1.jpg|Float variant taking off
c172p-preview3.jpg|Ski variant over Freiburg
c172p-preview4.jpg|About to land at Aosta Airport
c172p-panel-closeup.jpg|Panel close-up
c172p-preview6.jpg|Hazy day over Naples
c172p-preview8.jpg|Sightseeing at Chapada Diamantina
c172p-preview9.jpg|Bush take off
c172p-preview12.jpg|Night flight with dimmed post lights
c172p-panel-lighting.jpg|Full post lighting
c172p-preview10.jpg|Amphibian variant at Hawaii
c172p-preview11.jpg|Bush variant
c172p-panel-landing.jpg|About to land
c172p-ground-objects.jpg|PT-IAO with ground objects
c172p-particles.jpg|Taking off on water, showing the particle system
c172p-parked.jpg|N35799 livery parked at Camden Airport (YSCN)
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
</gallery>

== External links ==
* {{Wikipedia|Cessna 172|lang=en}}
* [https://www.aerodynamicaviation.com/members_docs/ Cessna 172P and other checklists and manuals at AeroDynamicAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[ar:Cessna 172P]]
[[ca:Cessna 172P]]
[[de:Cessna 172P]]
[[es:Cessna 172P]]
[[fr:Cessna 172P]]
[[nl:Cessna 172P]]
[[pl:Cessna 172P]]
[[ru:Cessna 172P]]
[[zh:Cessna 172P]]
[[Category:Red Griffin ATC compatible aircraft]]

Help:Main navigation elements

2026-07-02T21:22:22Z

Celesta:

{{Wiki help navbar}}

Three '''main navigation elements''' are available on each page of the FlightGear wiki (from top to bottom):

*The ''user links'' at the top right. These are linked to your account (if you have one)

* The ''page tabs'' above the page content. These are, for example, links to the discussion page and the revision history.
*The ''sidebar'' at the top left, links to various tools and links to other language versions of a page.

Although there are two ways to view wiki pages, the ''desktop view'' and the ''mobile view'', we will explain the ''desktop view'' here because the ''mobile view'' hides many features for the sake of simplicity. Features are described as they appear with the default skin.

{{TOC limit|2}}

==User links==
[[File:FlightGear wiki user links.png|frame|none|View of user links for a logged-in user]]

If you have an account and are logged in, the user links at the very top right are associated with your user account:

:;your user page
::Your user page, where you are encouraged to describe who you are and what ambitions you have on the wiki. You can also add sub-pages to your user page with, for example, drafts and other wiki projects.
:;Talk
::Your user talk page, where other users may be able to contact you. If your talk page has been edited by someone else, you will receive a notification the next time you log in or load another wiki page. You can also optionally configure your preferences to receive an email if your talk page has been edited.
:;Preferences
:: Your wiki preferences, where you can adjust and customize certain settings.
:;Watchlist
::Your [[Help:Tracking changes|watchlist]], which lists changes on pages you have "starred" and are watching.
:;Contributions
::A summary of your contributions and uploads to the wiki.
:;Log out
::By which you log out of your account.

==Page tabs==
[[File:FlightGear wiki page tabs.png|frame|none|The page tabs for a logged-in administrator (who can also delete and protect pages)]]

At the top of the page content, there is a set of tabs:

:;An article or page tab
::To view the article if you are on another tab or to go directly to the page if you have been redirected. The page tab also gives an indication of the type of page you are on.
:;a talk tab
::With the talk page for a wiki page or a user

;Read tab
:With exactly the same function as the page tab
;Edit or edit wiki code tab
: Which will allow you to edit a page on the wiki when you are logged in or see the page source if you are not.
;History tab
:Which will display the [[Help:Tracking changes|history]] of changes to a wiki page.
;Favorite tab (star)
:This will add or remove a page to or from your watchlist.
;More tab
:With a few extra functions, including a function to move pages (essentially renaming them). Wiki administrators also have a protection function and a deletion function.
:
==Sidebar==
[[File:FlightGear wiki sidebar.png|frame|right|The sidebar]]

At the top left is the sidebar with:

:;Navigation links
::To certain pages deemed important enough to be linked from every page:
::;The wiki home page
:::Where you end up by going to https://wiki.flightgear.org/
::; Recent changes
:::Listing the [[Help:Tracking changes#Recent changes|latest changes]] on the wiki
::;The village pump
:::The [[FlightGear wiki:Village pump|village pump]] is the wiki talk page not linked to a particular page or user.
::;The summary of help pages
::; The portal pages
:;FlightGear WEB sites
::*The home page https://www.flightgear.org
::* The forum https://forum.flightgear.org
::* The [[Mailing lists|mailing lists]] where developers coordinate
::*The [https://gitlab.com/flightgear source code repository] on GitLab
::*The {{tickets|bug tracker}} on GitLab
::*The [[FlightGear Scenery Database|scenery database]] FlightGear which contains landmarks, such as larger buildings, masts, and wind turbines
::*The [[FlightGear livery database|livery database]] with many additional liveries for popular aircraft
:;Toolbox
::Slightly dependent on the type of page you are viewing
::*A summary of pages linked to the page you are viewing
::*A summary of changes linked to the page you are viewing
::*The upload wizard
::*A set of special pages, with information on pages, categories, files, and users
::* A printable version of the page viewed
::*A link to the current revision of the page you are viewing
::*Information on the page you are viewing
:;Language links
::To versions of the page in other languages

==Category links==
[[File:FlightGear wiki category link footer.png|frame|right|Category link at the bottom of a wiki page]]

Categories will make it easier to navigate between related pages or images. If a page has been categorized, it will have links to the associated category pages at the bottom of the page. Category pages list the categories, pages, and files in that category and will contain links to any parent categories.

[[Category:Help|Navigation]]

[[fr:Aide:Main navigation elements]]

Help:Main navigation elements

2026-07-02T21:21:15Z

Celesta: /* Sidebar */

{{Wiki help navbar}}

Three '''main navigation elements''' are available on each page of the FlightGear wiki (from top to bottom):

*The ''user links'' at the top right. These are linked to your account (if you have one)

* The ''page tabs'' above the page content. These are, for example, links to the discussion page and the revision history.
*The ''sidebar'' at the top left, links to various tools and links to other language versions of a page.

Although there are two ways to view wiki pages, the ''desktop view'' and the ''mobile view'', we will explain the ''desktop view'' here because the ''mobile view'' hides many features for the sake of simplicity. Features are described as they appear with the default skin.

{{TOC limit|2}}

==User links==
[[File:FlightGear wiki user links.png|frame|none|View of user links for a logged-in user]]

If you have an account and are logged in, the user links at the very top right are associated with your user account:

:;your user page
::Your user page, where you are encouraged to describe who you are and what ambitions you have on the wiki. You can also add sub-pages to your user page with, for example, drafts and other wiki projects.
:;Talk
::Your user talk page, where other users may be able to contact you. If your talk page has been edited by someone else, you will receive a notification the next time you log in or load another wiki page. You can also optionally configure your preferences to receive an email if your talk page has been edited.
:;Preferences
:: Your wiki preferences, where you can adjust and customize certain settings.
:;Watchlist
::Your [[Help:Tracking changes|watchlist]], which lists changes on pages you have "starred" and are watching.
:;Contributions
::A summary of your contributions and uploads to the wiki.
:;Log out
::By which you log out of your account.

==Page tabs==
[[File:FlightGear wiki page tabs.png|frame|none|The page tabs for a logged-in administrator (who can also delete and protect pages)]]

At the top of the page content, there is a set of tabs:

:;An article or page tab
::To view the article if you are on another tab or to go directly to the page if you have been redirected. The page tab also gives an indication of the type of page you are on.
:;a talk tab
::With the talk page for a wiki page or a user

;Read tab
:With exactly the same function as the page tab
;Edit or edit wiki code tab
: Which will allow you to edit a page on the wiki when you are logged in or see the page source if you are not.
;History tab
:Which will display the [[Help:Tracking changes|history]] of changes to a wiki page.
;Favorite tab (star)
:This will add or remove a page to or from your watchlist.
;More tab
:With a few extra functions, including a function to move pages (essentially renaming them). Wiki administrators also have a protection function and a deletion function.
:
==Sidebar==
[[File:FlightGear wiki sidebar.png|frame|right|The sidebar]]

At the top left is the sidebar with:

:;Navigation links
::To certain pages deemed important enough to be linked from every page:
::;The wiki home page
:::Where you end up by going to https://wiki.flightgear.org/
::; Recent changes
:::Listing the [[Help:Tracking changes#Recent changes|latest changes]] on the wiki
::;The village pump
:::The [[FlightGear wiki:Village pump|village pump]] is the wiki talk page not linked to a particular page or user.
::;The summary of help pages
::; The portal pages
:;FlightGear WEB sites
::*The home page https://www.flightgear.org
::* The forum https://forum.flightgear.org
::* The [[Mailing lists|mailing lists]] where developers coordinate
::*The [https://gitlab.com/flightgear source code repository] on GitLab
::*The {{tickets|bug tracker}} on GitLab
::*The [[FlightGear Scenery Database|scenery database]] FlightGear which contains landmarks, such as larger buildings, masts, and wind turbines
::*The [[FlightGear livery database|livery database]] with many additional liveries for popular aircraft
:;Toolbox
::Slightly dependent on the type of page you are viewing
::*A summary of pages linked to the page you are viewing
::*A summary of changes linked to the page you are viewing
::*The upload wizard
::*A set of special pages, with information on pages, categories, files, and users
::* A printable version of the page viewed
::*A link to the current revision of the page you are viewing
::*Information on the page you are viewing
:;Language links
::To versions of the page in other languages

==Category links==
[[File:FlightGear wiki category link footer.png|frame|right|Category link at the bottom of a wiki page]]

Categories will make it easier to navigate between related pages or images. If a page has been categorized, it will have links to the associated category pages at the bottom of the page. Category pages list the categories, pages, and files in that category and will contain links to any parent categories.

[[Category:Aide|Navigation]]
[[Category:Help|Translate]]

[[en:Help:Main navigation elements]]
[[fr:Aide:Main navigation elements]]

Help:Main navigation elements

2026-07-02T21:02:33Z

Celesta: /* Sidebar */

{{Wiki help navbar}}

Three '''main navigation elements''' are available on each page of the FlightGear wiki (from top to bottom):

*The ''user links'' at the top right. These are linked to your account (if you have one)

* The ''page tabs'' above the page content. These are, for example, links to the discussion page and the revision history.
*The ''sidebar'' at the top left, links to various tools and links to other language versions of a page.

Although there are two ways to view wiki pages, the ''desktop view'' and the ''mobile view'', we will explain the ''desktop view'' here because the ''mobile view'' hides many features for the sake of simplicity. Features are described as they appear with the default skin.

{{TOC limit|2}}

==User links==
[[File:FlightGear wiki user links.png|frame|none|View of user links for a logged-in user]]

If you have an account and are logged in, the user links at the very top right are associated with your user account:

:;your user page
::Your user page, where you are encouraged to describe who you are and what ambitions you have on the wiki. You can also add sub-pages to your user page with, for example, drafts and other wiki projects.
:;Talk
::Your user talk page, where other users may be able to contact you. If your talk page has been edited by someone else, you will receive a notification the next time you log in or load another wiki page. You can also optionally configure your preferences to receive an email if your talk page has been edited.
:;Preferences
:: Your wiki preferences, where you can adjust and customize certain settings.
:;Watchlist
::Your [[Help:Tracking changes|watchlist]], which lists changes on pages you have "starred" and are watching.
:;Contributions
::A summary of your contributions and uploads to the wiki.
:;Log out
::By which you log out of your account.

==Page tabs==
[[File:FlightGear wiki page tabs.png|frame|none|The page tabs for a logged-in administrator (who can also delete and protect pages)]]

At the top of the page content, there is a set of tabs:

:;An article or page tab
::To view the article if you are on another tab or to go directly to the page if you have been redirected. The page tab also gives an indication of the type of page you are on.
:;a talk tab
::With the talk page for a wiki page or a user

;Read tab
:With exactly the same function as the page tab
;Edit or edit wiki code tab
: Which will allow you to edit a page on the wiki when you are logged in or see the page source if you are not.
;History tab
:Which will display the [[Help:Tracking changes|history]] of changes to a wiki page.
;Favorite tab (star)
:This will add or remove a page to or from your watchlist.
;More tab
:With a few extra functions, including a function to move pages (essentially renaming them). Wiki administrators also have a protection function and a deletion function.
:
==Sidebar==
[[File:FlightGear wiki sidebar.png|frame|right|The sidebar]]

At the top left is the sidebar with:

:;Navigation links
::To certain pages deemed important enough to be linked from every page:
::;The wiki home page
:::Where you end up by going to https://wiki.flightgear.org/
::; Recent changes
:::Listing the [[Help:Tracking changes#Recent changes|latest changes]] on the wiki
::;A random article
::;The village pump
:::The [[FlightGear wiki:Village pump|village pump]] is the wiki talk page not linked to a particular page or user.
::;The summary of help pages
::; The portal pages
:;FlightGear WEB sites
::*The home page https://www.flightgear.org
::* The forum https://forum.flightgear.org
::* The [[Mailing lists|mailing lists]] where developers coordinate
::*The [https://gitlab.com/flightgear source code repository] on SourceForge
::*The {{tickets|bug tracker}} on SourceForge
::*The [[FlightGear Scenery Database|scenery database]] FlightGear which contains landmarks, such as larger buildings, masts, and wind turbines
::*The [[FlightGear livery database|livery database]] with many additional liveries for popular aircraft
:;Toolbox
::Slightly dependent on the type of page you are viewing
::*A summary of pages linked to the page you are viewing
::*A summary of changes linked to the page you are viewing
::*The upload wizard
::*A set of special pages, with information on pages, categories, files, and users
::* A printable version of the page viewed
::*A link to the current revision of the page you are viewing
::*Information on the page you are viewing
:;Language links
::To versions of the page in other languages

==Category links==
[[File:FlightGear wiki category link footer.png|frame|right|Category link at the bottom of a wiki page]]

Categories will make it easier to navigate between related pages or images. If a page has been categorized, it will have links to the associated category pages at the bottom of the page. Category pages list the categories, pages, and files in that category and will contain links to any parent categories.

[[Category:Aide|Navigation]]
[[Category:Help|Translate]]

[[en:Help:Main navigation elements]]
[[fr:Aide:Main navigation elements]]

User:Celesta/removing old contents

2026-07-01T19:18:24Z

Celesta:

This page explains how I remove old content on this wiki.

=== Content ===
* "FlightGear uses OpenGL 2.0" '''=>''' "FlightGear uses OpenGL 4.0 and later"
* "FGRun" '''=>''' "Qt launcher/launcher" (or remove it)
* "<sourceforge link>" '''=>''' "<gitlab link if exists>", and "IRC" '''=>''' "Discord"

'''Versions'''

* "As of 2018.1, the feature ..." '''=>''' "As of 2018.1 and later, the feature ..." (more precise)
* "For FlightGear 2018.1 ..." '''=>''' "Since FlightGear 2018.1, ..."
* "As of 3.0 and later, the feature ..." '''=>''' "The feature ..." (remove the version reference entirely if the version (3.0) is too old)

=== Article format ===
* Move outdated status sections like "<nowiki>== Status == The feature was developed in 2016</nowiki>" to a "History" section, or remove them
* If the page is not about development (e.g., Nasal, Qt launcher), place background/history/feature request sections or outdated status sections at the bottom of the page. If the page is about development itself (e.g., Improving Nasal, Future of the Qt Launcher), you don't need to move these sections.
* Remove links of outdated or obsolete pages from the "related contents" section (or navigation bars).
* Reduce the number of quotes if there are too many.
* Remove first-person pronouns, such as "I".

[[Category:Wiki maintenance]]

FlightGear

2026-07-01T19:14:32Z

Celesta:

{{Infobox Software
|title = FlightGear Flight Simulator
|logo = FlightGear logo.png
|logosize = 200px
|image = Boeing 777-200ER cockpit.jpg
|alt = The cockpit of the [[Boeing 777-200ER]]
|developedby = FlightGear developers & contributors
|initialrelease = July 17, 1997
|latestrelease = {{current release|full}} ({{#time: j F Y |{{current release|fulldate}}}})
|writtenin = C/C++/Nasal
|os = Windows, macOS, Linux, and FreeBSD
|platform = Cross-platform
|developmentstatus = Active (1996-present)
|type = Flight simulator
|license = [[GNU General Public License]]
|website = http://www.flightgear.org/
}}
'''FlightGear Flight Simulator''' (often shortened to '''FlightGear''' or '''FGFS''') is a sophisticated, free, and completely open-source flight simulator framework, created by volunteers. FlightGear is released under the terms of the [[GNU General Public License]]. FlightGear is mostly written in the C and C++ programming languages.

Increasingly detailed and realistic versions of FlightGear have been released every year since the project was started in 1996.

The latest public release is [https://www.flightgear.org/download available as a free download], with easy to install packages for a variety of operating systems including Microsoft Windows, macOS, and Linux.

== History ==
{{main article|FlightGear History}}

FlightGear development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, FlightGear underwent a major change from [[PLIB]] to [[OSG]], which caused a temporarily loss of some features like 3D clouds and shadows.

== Software ==

The simulation engine in FlightGear is called [[SimGear]]. It is used both as an end-user application and in academic and research environments, for the development and pursuit of flight simulation ideas.

This customizability of FlightGear is illustrated by the wide range of [[aircraft|aircraft models]] that are available in FlightGear, from [[:Category:Gliders|glider]]s to [[Helicopter]]s, and from [[:Category:Airliners|airliners]] to [[Military aircraft|fighter jets]]. These aircraft models have been contributed by many different people.

The FlightGear aircraft in general use one of two main flight data models [[JSBSim]] and [[YASim]]. Currently only one terrain engine is used, TerraGear. Weather effects include 3D clouds, lighting effects, and time of day.

=== Flight Dynamics Models ===
[[Flight Dynamics Models]] (FDM) are how the flight for an aircraft is simulated in the program. FlightGear uses a variety of internally written and imported flight model projects. Any aircraft must be programmed to use one of these models. Currently FlightGear is the only flight graphical flight simulator all the FDM are used for, and UIUC and YASim were developed specifically for FlightGear.

Early version used a FDM based on [[LaRCsim]] by NASA, which was replaced with more flexible FDM.

* [[JSBSim]] - the default flight dynamics model software since 2000.
* [[YASim]] - another FDM using different calculation method. Introduced starting in 0.7.9 in 2002.
* [[UIUC]] - developed by the UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, also made use of LaRCsim. Once being widely used, it is no longer included in FlightGear.
* FlightGear can also be setup to render using inputs from an external FDM source, such as from [[MATLAB]].
* Other custom FDM for a specific aircraft type have been written, such as for lighter than air aircraft.

=== Aircraft ===
{{Main article|aircraft}}

[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 737]] docked in the [[EHAM]] scenery]]

FlightGear started out with one aircraft included in NASA's LaRCsim, a [[Navion]], which was replaced by a [[Cessna 172]] by 2000. UIUC as well as JSBSim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. Over 600 aircraft in more than 1200 unique liveries, are available for version 2024.1, although only a few are included in the base package.

=== Scenery ===
{{Main article|Scenery}}
FlightGear's [[world scenery]] project contains elevation and landclass data of the entire world. Objects, like terminals, windmills and bridges, are collected in the [[FlightGear Scenery Database|Scenery Database]].

=== Networking and multi-display ===
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Howto:Multiplayer|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.

Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.

==Applications and usages==
{{Main article|Professional and educational FlightGear users}}
FlightGear has been used and is being used in a wide range of projects in academia, industry (including NASA) and home-built cockpits.

== External links ==
{{Main article|Links}}
* [https://www.flightgear.org Official website]
* {{forum link|text=Forum}}
* {{tickets|Bug tracker}}
* [https://www.flightgear.org/blog/proposal-1-0/ Original FlightGear proposal]
* {{Wikipedia|FlightGear}}

[[Category:FlightGear]]

[[ca:FlightGear]]
[[de:FlightGear]]
[[es:FlightGear]]
[[fr:FlightGear]]
[[it:FlightGear]]
[[nl:FlightGear]]
[[pl:FlightGear]]
[[pt:FlightGear]]
[[pt-br:FlightGear]]
[[ru:FlightGear]]

FlightGear

2026-07-01T19:13:54Z

Celesta: move to history page

{{Infobox Software
|title = FlightGear Flight Simulator
|logo = FlightGear logo.png
|logosize = 200px
|image = Boeing 777-200ER cockpit.jpg
|alt = The cockpit of the [[Boeing 777-200ER]]
|developedby = FlightGear developers & contributors
|initialrelease = July 17, 1997
|latestrelease = {{current release|full}} ({{#time: j F Y |{{current release|fulldate}}}})
|writtenin = C/C++/Nasal
|os = Windows, macOS, Linux, and FreeBSD
|platform = Cross-platform
|developmentstatus = Active (1996-present)
|type = Flight simulator
|license = [[GNU General Public License]]
|website = http://www.flightgear.org/
}}
'''FlightGear Flight Simulator''' (often shortened to '''FlightGear''' or '''FGFS''') is a sophisticated, free, and completely open-source flight simulator framework, created by volunteers. FlightGear is released under the terms of the [[GNU General Public License]]. FlightGear is mostly written in the C and C++ programming languages.

Increasingly detailed and realistic versions of FlightGear have been released every year since the project was started in 1996.

The latest public release is [https://www.flightgear.org/download available as a free download], with easy to install packages for a variety of operating systems including Microsoft Windows, macOS, and Linux.

== History ==
{{main article|FlightGear History}}

FlightGear development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, FlightGear underwent a major change from [[PLIB]] to [[OSG]], which caused a temporarily loss of some features like 3D clouds and shadows.

== Software ==

The simulation engine in FlightGear is called [[SimGear]]. It is used both as an end-user application and in academic and research environments, for the development and pursuit of flight simulation ideas.

This customizability of FlightGear is illustrated by the wide range of [[aircraft|aircraft models]] that are available in FlightGear, from [[:Category:Gliders|glider]]s to [[Helicopter]]s, and from [[:Category:Airliners|airliners]] to [[Military aircraft|fighter jets]]. These aircraft models have been contributed by many different people.

The FlightGear aircraft in general use one of two main flight data models [[JSBSim]] and [[YASim]]. Currently only one terrain engine is used, TerraGear. Weather effects include 3D clouds, lighting effects, and time of day.

=== Flight Dynamics Models ===
[[Flight Dynamics Models]] (FDM) are how the flight for an aircraft is simulated in the program. FlightGear uses a variety of internally written and imported flight model projects. Any aircraft must be programmed to use one of these models. Currently FlightGear is the only flight graphical flight simulator all the FDM are used for, and UIUC and YASim were developed specifically for FlightGear.

Early version used a FDM based on [[LaRCsim]] by NASA, which was replaced with more flexible FDM.

* [[JSBSim]] - the default flight dynamics model software since 2000.
* [[YASim]] - another FDM using different calculation method. Introduced starting in 0.7.9 in 2002.
* [[UIUC]] - developed by the UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, also made use of LaRCsim. Once being widely used, it is no longer included in FlightGear.
* FlightGear can also be setup to render using inputs from an external FDM source, such as from [[MATLAB]].
* Other custom FDM for a specific aircraft type have been written, such as for lighter than air aircraft.

=== Aircraft ===
{{Main article|aircraft}}

FlightGear started out with one aircraft included in NASA's LaRCsim, a [[Navion]], which was replaced by a [[Cessna 172]] by 2000. UIUC as well as JSBSim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. Over 600 aircraft in more than 1200 unique liveries, are available for version 2024.1, although only a few are included in the base package.

[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 737]] docked in the [[EHAM]] scenery]]

=== Scenery ===
{{Main article|Scenery}}
FlightGear's [[world scenery]] project contains elevation and landclass data of the entire world. Objects, like terminals, windmills and bridges, are collected in the [[FlightGear Scenery Database|Scenery Database]].

=== Networking and multi-display ===
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Howto:Multiplayer|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.

Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.

==Applications and usages==
{{Main article|Professional and educational FlightGear users}}
FlightGear has been used and is being used in a wide range of projects in academia, industry (including NASA) and home-built cockpits.

== External links ==
{{Main article|Links}}
* [https://www.flightgear.org Official website]
* {{forum link|text=Forum}}
* {{tickets|Bug tracker}}
* [https://www.flightgear.org/blog/proposal-1-0/ Original FlightGear proposal]
* {{Wikipedia|FlightGear}}

[[Category:FlightGear]]

[[ca:FlightGear]]
[[de:FlightGear]]
[[es:FlightGear]]
[[fr:FlightGear]]
[[it:FlightGear]]
[[nl:FlightGear]]
[[pl:FlightGear]]
[[pt:FlightGear]]
[[pt-br:FlightGear]]
[[ru:FlightGear]]

FlightGear history

2026-07-01T19:12:28Z

Celesta:

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, FlightGear underwent a major change from [[PLIB]] to [[OSG]], which caused a temporarily loss of some features like 3D clouds and shadows.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olson starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 

"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGL was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.'' 
''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 

Rather than start entirely from scratch, FlightGear developers made use of the [[LaRCsim]] flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Version 2018.1 "Honolulu" (2018) ==
Released in April 2018, version 2018.1 was the first major update in the 2018 release cycle. This version focused on environmental realism and significant improvements to the YASim flight dynamics model (FDM), including support for multiple wing sections to model variable wing geometry. The "Honolulu" release featured PHNL as the default airport and introduced active volcanoes such as Kilauea and Etna, which integrated environmental physics by generating increased turbulence in their vicinity. The [[Atmospheric light scattering|ALS (Atmospheric Light Scattering)]] renderer was also updated with extra volumetric vegetation layers for denser undergrowth.

== Version 2019.1 (2019) ==
Version 2019.1, released in March 2019, introduced the "Compositor," an experimental XML-configurable rendering framework designed to replace legacy hard-coded rendering paths. This framework enabled advanced post-processing effects and Cascaded Shadow Mapping (CSM) for more realistic environmental shadows. Other technical advancements included the introduction of a DDS Texture Cache to speed up loading times and the implementation of 8.33 kHz radio frequency spacing for aircraft like the [[Boeing 777]] to comply with modern European airspace requirements.

== Version 2020.1 and 2020.3 LTS (2020) ==
The 2020 cycle saw the release of 2020.1 in May and the Long Term Support (LTS) version, 2020.3, in October. This era was marked by a shift toward data integrity, particularly in the JSBSim FDM, where gyros were updated to measure rotation rates rather than rotational accelerations to better match physical reality. Graphical performance was enhanced through instanced-based rendering for OpenStreetMap (OSM) buildings, which was later integrated into the [[TerraSync]] system (v2020.3.7) for global coverage. The release also featured expanded aircraft carrier support with new launcher options for takeoff and approach positions.

== Version 2024.1 (2025-2026) ==
Replacing the 2020.3 LTS, version 2024.1 (officially released in February 2025 as v2024.1.1) represents a major technological pivot for the project. Key highlights include:

* [[VR]] Support: Preliminary integration of VR headsets using the OpenXR standard.

* [[World Scenery 3.0]] (WS3.0): A preview of a new Quadtree-based scenery system utilizing Virtual Planet Builder, providing higher frame rates and lower memory usage through multiple levels of detail.

* Dynamic Lighting and Shadows: Real-time dynamic shadows and lighting were added to the core rendering engine.

* Climate Modeling: The legacy season selection was replaced with a holistic climate model calculating environmental factors like snow lines and ocean temperatures dynamically.

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11, 1998 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| Oct 13, 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|-
| Jul 26, 2021 || 2020.3.10
|-
| Jul 29, 2021 || 2020.3.11
|-
|Feb 6, 2022
|2020.3.12
|-
|Mar 30, 2022
|2020.3.13
|-
|Sep 27, 2022
|2020.3.14
|-
|Oct 12, 2022
|2020.3.15
|-
|Oct 20, 2022
|2020.3.16
|-
|Sep 22, 2022
|2020.3.17
|-
|Mar 21, 2023
|2020.3.18
|-
|Feb 27, 2025
|2024.1.1
|-
|Sep 18, 2025
|2024.1.2
|-
|Nov 2, 2025
|2024.1.3
|-
|Jan 21, 2026
|2024.1.4
|-
|Mar 22, 2026
|2024.1.5
|-
|June 4, 2026
|2024.1.6
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release (except 2024.1, for whatever reason).

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="4" | [[BIKF]] || rowspan="4" | Keflavik
|-
| 2020.2
|-
| 2020.3
|-
| 2024.1
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [https://github.com/clolsonus/FlightGear-vault Historic FlightGear code since 1996] ([https://forum.flightgear.org/viewtopic.php?f=42&t=42351 forum])
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}
[[fr:FlightGear history]]

[[Category:FlightGear]]
[[Category:Articles to be updated for each release]]

FlightGear

2026-07-01T19:10:09Z

Celesta: /* History */

{{Infobox Software
|title = FlightGear Flight Simulator
|logo = FlightGear logo.png
|logosize = 200px
|image = Boeing 777-200ER cockpit.jpg
|alt = The cockpit of the [[Boeing 777-200ER]]
|developedby = FlightGear developers & contributors
|initialrelease = July 17, 1997
|latestrelease = {{current release|full}} ({{#time: j F Y |{{current release|fulldate}}}})
|writtenin = C/C++/Nasal
|os = Windows, macOS, Linux, and FreeBSD
|platform = Cross-platform
|developmentstatus = Active (1996-present)
|type = Flight simulator
|license = [[GNU General Public License]]
|website = http://www.flightgear.org/
}}
[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]
'''FlightGear Flight Simulator''' (often shortened to '''FlightGear''' or '''FGFS''') is a sophisticated, free, and completely open-source flight simulator framework, created by volunteers. FlightGear is released under the terms of the [[GNU General Public License]]. FlightGear is mostly written in the C and C++ programming languages.

Increasingly detailed and realistic versions of FlightGear have been released every year since the project was started in 1996.

The latest public release is [https://www.flightgear.org/download available as a free download], with easy to install packages for a variety of operating systems including Microsoft Windows, macOS, and Linux.

== History ==
{{main article|FlightGear History}}

FlightGear development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

In 2008, FlightGear underwent a major change from [[PLIB]] to [[OSG]], which caused a temporarily loss of some features like 3D clouds and shadows.

== Software ==

The simulation engine in FlightGear is called [[SimGear]]. It is used both as an end-user application and in academic and research environments, for the development and pursuit of flight simulation ideas.

This customizability of FlightGear is illustrated by the wide range of [[aircraft|aircraft models]] that are available in FlightGear, from [[:Category:Gliders|glider]]s to [[Helicopter]]s, and from [[:Category:Airliners|airliners]] to [[Military aircraft|fighter jets]]. These aircraft models have been contributed by many different people.

The FlightGear aircraft in general use one of two main flight data models [[JSBSim]] and [[YASim]]. Currently only one terrain engine is used, TerraGear. Weather effects include 3D clouds, lighting effects, and time of day.

=== Flight Dynamics Models ===
[[Flight Dynamics Models]] (FDM) are how the flight for an aircraft is simulated in the program. FlightGear uses a variety of internally written and imported flight model projects. Any aircraft must be programmed to use one of these models. Currently FlightGear is the only flight graphical flight simulator all the FDM are used for, and UIUC and YASim were developed specifically for FlightGear.

Early version used a FDM based on [[LaRCsim]] by NASA, which was replaced with more flexible FDM.

* [[JSBSim]] - the default flight dynamics model software since 2000.
* [[YASim]] - another FDM using different calculation method. Introduced starting in 0.7.9 in 2002.
* [[UIUC]] - developed by the UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, also made use of LaRCsim. Once being widely used, it is no longer included in FlightGear.
* FlightGear can also be setup to render using inputs from an external FDM source, such as from [[MATLAB]].
* Other custom FDM for a specific aircraft type have been written, such as for lighter than air aircraft.

=== Aircraft ===
{{Main article|aircraft}}

FlightGear started out with one aircraft included in NASA's LaRCsim, a [[Navion]], which was replaced by a [[Cessna 172]] by 2000. UIUC as well as JSBSim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. Over 600 aircraft in more than 1200 unique liveries, are available for version 2024.1, although only a few are included in the base package.

[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 737]] docked in the [[EHAM]] scenery]]

=== Scenery ===
{{Main article|Scenery}}
FlightGear's [[world scenery]] project contains elevation and landclass data of the entire world. Objects, like terminals, windmills and bridges, are collected in the [[FlightGear Scenery Database|Scenery Database]].

=== Networking and multi-display ===
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Howto:Multiplayer|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.

Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.

==Applications and usages==
{{Main article|Professional and educational FlightGear users}}
FlightGear has been used and is being used in a wide range of projects in academia, industry (including NASA) and home-built cockpits.

== External links ==
{{Main article|Links}}
* [https://www.flightgear.org Official website]
* {{forum link|text=Forum}}
* {{tickets|Bug tracker}}
* [https://www.flightgear.org/blog/proposal-1-0/ Original FlightGear proposal]
* {{Wikipedia|FlightGear}}

[[Category:FlightGear]]

[[ca:FlightGear]]
[[de:FlightGear]]
[[es:FlightGear]]
[[fr:FlightGear]]
[[it:FlightGear]]
[[nl:FlightGear]]
[[pl:FlightGear]]
[[pt:FlightGear]]
[[pt-br:FlightGear]]
[[ru:FlightGear]]

FlightGear history

2026-07-01T19:09:04Z

Celesta:

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused a temporarily loss of some features like 3D clouds and shadows.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olson starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 

"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGL was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.'' 
''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 

Rather than start entirely from scratch, FlightGear developers made use of the [[LaRCsim]] flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Version 2018.1 "Honolulu" (2018) ==
Released in April 2018, version 2018.1 was the first major update in the 2018 release cycle. This version focused on environmental realism and significant improvements to the YASim flight dynamics model (FDM), including support for multiple wing sections to model variable wing geometry. The "Honolulu" release featured PHNL as the default airport and introduced active volcanoes such as Kilauea and Etna, which integrated environmental physics by generating increased turbulence in their vicinity. The [[Atmospheric light scattering|ALS (Atmospheric Light Scattering)]] renderer was also updated with extra volumetric vegetation layers for denser undergrowth.

== Version 2019.1 (2019) ==
Version 2019.1, released in March 2019, introduced the "Compositor," an experimental XML-configurable rendering framework designed to replace legacy hard-coded rendering paths. This framework enabled advanced post-processing effects and Cascaded Shadow Mapping (CSM) for more realistic environmental shadows. Other technical advancements included the introduction of a DDS Texture Cache to speed up loading times and the implementation of 8.33 kHz radio frequency spacing for aircraft like the [[Boeing 777]] to comply with modern European airspace requirements.

== Version 2020.1 and 2020.3 LTS (2020) ==
The 2020 cycle saw the release of 2020.1 in May and the Long Term Support (LTS) version, 2020.3, in October. This era was marked by a shift toward data integrity, particularly in the JSBSim FDM, where gyros were updated to measure rotation rates rather than rotational accelerations to better match physical reality. Graphical performance was enhanced through instanced-based rendering for OpenStreetMap (OSM) buildings, which was later integrated into the [[TerraSync]] system (v2020.3.7) for global coverage. The release also featured expanded aircraft carrier support with new launcher options for takeoff and approach positions.

== Version 2024.1 (2025-2026) ==
Replacing the 2020.3 LTS, version 2024.1 (officially released in February 2025 as v2024.1.1) represents a major technological pivot for the project. Key highlights include:

* [[VR]] Support: Preliminary integration of VR headsets using the OpenXR standard.

* [[World Scenery 3.0]] (WS3.0): A preview of a new Quadtree-based scenery system utilizing Virtual Planet Builder, providing higher frame rates and lower memory usage through multiple levels of detail.

* Dynamic Lighting and Shadows: Real-time dynamic shadows and lighting were added to the core rendering engine.

* Climate Modeling: The legacy season selection was replaced with a holistic climate model calculating environmental factors like snow lines and ocean temperatures dynamically.

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11, 1998 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| Oct 13, 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|-
| Jul 26, 2021 || 2020.3.10
|-
| Jul 29, 2021 || 2020.3.11
|-
|Feb 6, 2022
|2020.3.12
|-
|Mar 30, 2022
|2020.3.13
|-
|Sep 27, 2022
|2020.3.14
|-
|Oct 12, 2022
|2020.3.15
|-
|Oct 20, 2022
|2020.3.16
|-
|Sep 22, 2022
|2020.3.17
|-
|Mar 21, 2023
|2020.3.18
|-
|Feb 27, 2025
|2024.1.1
|-
|Sep 18, 2025
|2024.1.2
|-
|Nov 2, 2025
|2024.1.3
|-
|Jan 21, 2026
|2024.1.4
|-
|Mar 22, 2026
|2024.1.5
|-
|June 4, 2026
|2024.1.6
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release (except 2024.1, for whatever reason).

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="4" | [[BIKF]] || rowspan="4" | Keflavik
|-
| 2020.2
|-
| 2020.3
|-
| 2024.1
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [https://github.com/clolsonus/FlightGear-vault Historic FlightGear code since 1996] ([https://forum.flightgear.org/viewtopic.php?f=42&t=42351 forum])
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}
[[fr:FlightGear history]]

[[Category:FlightGear]]
[[Category:Articles to be updated for each release]]

User:Celesta/removing old contents

2026-07-01T17:44:53Z

Celesta: /* Article format */

This page explains how I remove old content on this wiki.

=== Content ===
* "FlightGear uses OpenGL 2.0" '''=>''' "FlightGear uses OpenGL 4.0 and later"
* "FGRun" '''=>''' "Qt launcher/launcher" (or remove it)
* "<sourceforge link>" '''=>''' "<gitlab link if exists>", and "IRC" '''=>''' "Discord"

'''Versions'''

* "As of 2018.1, the feature ..." '''=>''' "As of 2018.1 and later, the feature ..." (more precise)
* "For FlightGear 2018.1 ..." '''=>''' "Since FlightGear 2018.1, ..."
* "As of 3.0 and later, the feature ..." '''=>''' "The feature ..." (remove the version reference entirely if the version (3.0) is too old)

=== Article format ===
* Move outdated status sections like "<nowiki>== Status == The feature was developed in 2016</nowiki>" to a "History" section, or remove them
* If the page is not about development (e.g., Nasal, Qt launcher), place background/history/feature request sections or outdated status sections at the bottom of the page. If the page is about development itself (e.g., Improving Nasal, Future of the Qt Launcher), you don't need to move these sections.
* Remove links of outdated or obsolete pages from the "related contents" section (or navigation bars).
* Reduce the number of quotes if there are too many.
* Remove unnecessary first-person pronouns, such as "I".

[[Category:Wiki maintenance]]

User:Celesta/removing old contents

2026-07-01T17:43:55Z

Celesta:

This page explains how I remove old content on this wiki.

=== Content ===
* "FlightGear uses OpenGL 2.0" '''=>''' "FlightGear uses OpenGL 4.0 and later"
* "FGRun" '''=>''' "Qt launcher/launcher" (or remove it)
* "<sourceforge link>" '''=>''' "<gitlab link if exists>", and "IRC" '''=>''' "Discord"

'''Versions'''

* "As of 2018.1, the feature ..." '''=>''' "As of 2018.1 and later, the feature ..." (more precise)
* "For FlightGear 2018.1 ..." '''=>''' "Since FlightGear 2018.1, ..."
* "As of 3.0 and later, the feature ..." '''=>''' "The feature ..." (remove the version reference entirely if the version (3.0) is too old)

=== Article format ===
* Move outdated status sections like "<nowiki>== Status == The feature was developed in 2016</nowiki>" to a "History" section, or remove them
* If the page is not about development (e.g., Nasal, Qt launcher), place background/history/feature request sections or outdated status sections at the bottom of the page. If the page is about development itself (e.g., Improving Nasal, Future of the Qt Launcher), you don't need to move these sections.
* Remove links of outdated or obsolete pages from the "related contents" section (or navigation bars).
* Reduce the number of quotes if there are too many.
* Remove unnecessary first-person pronouns.

[[Category:Wiki maintenance]]

Howto:Create a flightplan

2026-07-01T17:40:37Z

Celesta: redirect old content to Flight planning

#redirect [[Flight planning]]

Creating a flightplan

2026-07-01T17:40:16Z

Celesta: Changed redirect target from Howto:Create a flightplan to Flight planning

#REDIRECT [[Flight planning]]

Understanding navigation

2026-07-01T17:39:43Z

Celesta: links to manual

There are two ways of navigation, '''visual navigation''' and '''instrument navigation'''. These are usually referred to as '''VFR''' and '''IFR navigation''' as a pilot has to adhere to [[Flight rules#Visual flight rules|visual flight rules]] or [[Flight rules#Instrument flight rules|instrument flight rules]].

Both are useful in their right circumstances, but instrument navigation works well in situations were visual navigation would not be useful, in essence in bad weather.

{{cquote|Understanding and using basic navigation concepts is important to fully enjoy flight simulators, too.|Charles Wood.}}

== Visual navigation ==
: ''See also [[pilotage and dead reckoning]].''

Visual navigation in its easiest way, often called pilotage, just means looking out of the window and comparing the outside with a map or with what you know about the area.

If the timing is important you also bring in dead reckoning. This includes more planning and using the compass and a clock to keep track of what terrain or man-made features you can expect to come next, were to turn to the next heading etc.

A [[VFR]] tutorial can be found in the [https://flightgear.gitlab.io/getstart/release-{{current release|cr}}/en/HTML/getstart-ench9.html FlightGear Manual].

== Instrument navigation ==
For instrument navigation you can rely completely on your instruments and [[radio beacons]]. The view outside is not necessary at all. Instrument navigation is needed, when you do not have any external references, that you can use for orientation. Just imagine flying through a cloud or at night.

Instrument navigation might be using
* [[Radio navigation]] and similar ([https://flightgear.gitlab.io/getstart/release-{{current release|cr}}/en/HTML/getstart-ench10.html tutorial from the FlightGear Manual])
* The [[route manager]]
* [[GPS|GPS navigation]]

== External links ==
=== On-line navigational tools ===
* http://mpmap02.flightgear.org/v3/?ll=48.78639071904214,3.760316710937488&z=4&t=m&fg_server=mpserver01:5000,mpserver01.flightgear.org,5001&update_interval=5&pilot_label=mouseover&icon_mode=normal
* https://mpserver12.org/livemap/
* [http://mapserver.flightgear.org/ Mapserver for FlightGear] (dead link)
* [http://skyvector.com/ SkyVector Simulator Flight Planning map tool]

=== Resources ===
* A very comprehensive website teaching the concepts and history of navigation by navigational aids ([[navaids]]) is [http://www.navfltsm.addr.com Flight Simulator Navigation] maintained by Charles Wood.
* Another useful document is the [http://www.calclassic.com/propliner_tutorial.htm Propliner Tutorial] which discusses navigational methods from the early pioneering years of aviation until the end of propliner era.
* http://selair.selkirk.ca/Training/Navigation/pdf/IFR%20for%20Professional%20Pilots.pdf
* http://www.americanflyers.net/aviationlibrary/instrument_flying_handbook/chapter_7.htm

{{Understanding}}

[[de:Flugnavigation]]
[[es:Entendiendo_la_navegación]]
[[pt:Entendendo Navegacao]]
[[pl:Nawigacja]]

FlightGear wiki:FlightGear screenshot categories

2026-07-01T17:33:18Z

Celesta: /* Aircraft related categories */

The '''FlightGear screenshot categories''' contains image files with in-sim screenshots of aircraft, scenery, the user interface etc. uploaded primarily for the purpose of illustrating wiki articles.

The categories main purpose is to group together screenshots of related subjects and to encourage and facilitate browsing between those subjects. They purpose is also to facilitate browsing between article and screenshot categories.

== General structure ==
:''See also [[Special:CategoryTree/FlightGear screenshots]].''

In short the files are categorized in a structure resembling several trees with intertwined branches sometimes with webs between them.

To facilitate looking for a specific screenshot subject, the categories are structured a bit like trees going from more general categories further out the branches to more specialized subjects, for example screenshots of details of the cockpit of a specific aircraft.

To further facilitate browsing, categories with a similar type of content are also linked together resulting in that some category trees appear intertwined. As some category trees are closely following each other they are also more tightly coupled and intertwined with each other.

In particular article and screenshot categories related to each other are intertwined and closely coupled with each other. Two examples of such structures are [[:Category:Aircraft by type]] and [[:Category:Screenshots of aircraft by type]], and [[:Category:Airports]] and [[:Category:Screenshots of airports]].

== Making files easy to find ==
=== Good file description ===
The best way to make a file easy to find really is to use a descriptive file name and add a good file description. That way it can much easier be found, whether that be with with the wiki's [[Special:Search|search function]] or with external search providers (like Google search).

=== Good use of categories ===
The categories are not tags, but a group of similar items that can be browsed by traversing related groups through links between the categories.

By adding a few categories that are as specific as possible, a file can be found easier. Conversely, adding many "tags" would clutter the category pages and make it harder to find a specific file on a category page.

To find a good category either use the [[Special:CategoryTree/FlightGear screenshots|category tree]] or the blue triangles in the ''Subcategories'' section on a [[:Category:FlightGear screenshots|category page]].

== Specific category structures ==
=== Aircraft related categories ===
:''See also [[Special:CategoryTree/Screenshots of aircraft]].''

The aircraft article and aircraft screenshot category trees are closely coupled to and intertwined with each other to simplify browsing them. Both the article and the screenshots categories have a subtree by aircraft type. The screenshot category structure follows the article category structure, which in turn follows the Wikipedia category structure ({{Wikipedia|Category:Aircraft by type}}).

Some aircraft have a subtree like below:
: ▼ Aircraft screenshot category
:: ▼ Cockpit screenshot category
::: ► Cockpit details screenshot category
:: ► Custom dialog screenshot category

=== Scenery related categories ===
:''See also [[Special:CategoryTree/Screenshots of scenery]].''

Similar to the aircraft category structures, the scenery and in particular airport related categories are intertwined with each other.

Both the scenery and airport article categories as well as the scenery and airport screenshot categories are divided into continents, countries and airports. All the four category structures are closely coupled and intertwined with each other.

=== Dialog categories ===
:''See also [[Special:CategoryTree/FlightGear dialog screenshots]].''

This category subtree mainly consists of screenshots of dialogs and also contains aircraft specific custom dialog screenshot categories.

== Creating new subcategories ==
Creating new subcategories, ''category diffusion'', by splitting off related files into new subcategories will help finding specific files, if it is done in a consistent and logical way.

As a rule of thumb a new subcategory could or should be created when there is somewhere between three to seven files that are strongly related to each other, for example by being screenshots of the cockpit of the same aircraft.

=== Subcategory page contents ===
In order to make a subcategory useful the category page should contain:

* A good category description, either using {{tl|fg screenshot cat}}, the {{tl|en}} or another [[:Category:Language templates|language template]].
* Links in the description to any related articles
* A category link to the main category
* Maybe category links to some related categories (including article categories)

It is often useful to use [[Help:Categories#Using a sort key|category sorting]] in the category links

== Related content ==
* [[Help:Categories]]
* {{tl|fg screenshot cat}}
* [[:Category:FlightGear screenshots]]

[[Category:FlightGear wiki]]
[[Category:FlightGear screenshots| ]]

Space Shuttle

2026-07-01T17:30:56Z

Celesta: reference section

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]] 
 
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===
{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688 ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777 forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|800px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|800px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===
* [[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

* [[Flying the Shuttle - Launch]]
* [[Flying the Shuttle - Orbital Operations]]
* [[Flying the Shuttle - Entry]]
* [[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

* [[Flying the Shuttle - Launch And Post Insertion Advanced]]
* [[Flying the Shuttle - Deorbit Preparation Advanced]]
* [[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]
* [[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

* [[Flying the Shuttle - Intact Abort Procedures Overview]]
* [[Flying the Shuttle - Return To Launch Site RTLS]]
* [[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click the picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

== External links ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

=== FlightGear related ===

'''Videos'''

A compilation of in FG Sim videos about the Space Shuttle:

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

'''Mission reports'''

A compilation of Space Shuttle stories / mission reports from the forum.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== References ==
{{appendix}}

[[Category:Space Shuttle documentation]]

Space Shuttle

2026-07-01T17:27:20Z

Celesta:

Space Shuttle

2026-07-01T17:18:32Z

Celesta: /* Mission phases */ format

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]] 
 
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===
{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688 ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777 forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|1000px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|1000px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===
* [[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

* [[Flying the Shuttle - Launch]]
* [[Flying the Shuttle - Orbital Operations]]
* [[Flying the Shuttle - Entry]]
* [[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

* [[Flying the Shuttle - Launch And Post Insertion Advanced]]
* [[Flying the Shuttle - Deorbit Preparation Advanced]]
* [[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]
* [[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

* [[Flying the Shuttle - Intact Abort Procedures Overview]]
* [[Flying the Shuttle - Return To Launch Site RTLS]]
* [[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Educational Links / Shuttle technical files ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

== Videos ==

A compilation of in FG Sim videos about the Space Shuttle

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

== Mission reports ==

A compilation of Space Shuttle stories / mission reports.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

[[Category:Space Shuttle documentation]]

Shuttle guidance - TAEM/Approach and Autoland guidance

2026-07-01T17:16:21Z

Celesta: documentation

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688 ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777 forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

=== TAEM ===

'''1) TGXHAC'''

It is the initial TAEM computation where the HAC is defined following what we choose in the Spec 50 display (Runway / Overhead or Straight-In / NEP or MEP / etc)
Aim point is also taken into account (7500 feet or 6500 feet)
[[File:TGXHAC.webp|400px|thumbnail|none]]

Another important factor that is calculated there is the final glideslope value for the A/L final path (starting at 10000 feet / 6Nm).
It can be either 18° for a heavy weight (more than 220000 lbs) or 20° for a lighter Shuttle.
That was changed later in the STS program to take into account the nominal mid-value for Speedbrake effectiveness (65°).
That slope combination was then choosen.
[[File:OGS geometry.webp|600px|thumbnail|none]]

In the november 2024 dev branch, we can clearly see it now at Approach/Landing Interface in the HUD and PFD glideslope deviation.
Left HUD for Heavy / Right for Light
[[File:HUD OGS.webp|600px|thumbnail|none]]

'''2) GTP (Ground Track Computations)'''

The distance to the runway is computed in that function.

*Left and Center Picture (Before and into the HAC): The range to go is the sum of the distance to be flown while aligning with the HAC entry point(ARCAC), the distance to be flown to that tangent WP1 (RTAN), the distance to be flown into the HAC up to the threshold (RPRED2)
*Right picture: Once close enough to the final runway course, distance forecasted becomes a direct distance to the runway threshold.
[[File:GTP overview.webp|600px|thumbnail|none]]

'''3) TGCOMP (General Computations)'''

All the computations for reference parameters are done there.

*The Altitude reference
A mix between linear and cubic segments.
Up to 40 Nmish in blue, a low slope linear profile (6° ish of slope)
Between A/L interface ( 6Nm) and 40 Nm, the green cubic segment where the slope increases up to the final Gamma targeted (18/20°)
At A/L interface, the red linear segment for final slope.
[[File:TAEM altitude profile.webp|600px|thumbnail|none]]

*The Specific Energy reference
That allows to shape the Nominal Energy path based on the True Airspeed and Altitude.
S-turn / Nominal / Low Energy boundaries.

Left picture is the Energy lines I took as a reference (closer to the latest Energy profiles flown in the later part of STS program )
Right picture shows that those lines are "just" some linear functions with some breakpoints here and there.
[[File:TAEM EW.webp|600px|thumbnail|none]]

*Dynamic Pressure Reference Profile
It is basically the EAS targeted.
[[File:TAEM QBAR.webp|600px|thumbnail|none]]

I adjusted it also to be closer to the latest QBAR profile flown (a tad higher, 305 psf targeted at A/L ie. 300 kts instead of 275 kts)
It will be coherent with the EAS visible in the Vert Traj display.
[[File:TAEM mm305.webp|600px|thumbnail|none]]

Another small logic for Low Energy handling: ''HAC radius shrinking''.

The final HAC radius (past 90° into the HAC) is 14000 feet (2.3 Nm).
In case of Low Energy once into the HAC and before the 90° HAC angle to go, the final radius will shrink depending on how Low we are in Potential Energy (up to a final radius of 5000 feet).
Basically, it means to be 4000 feet ish low on the glidepath once into the HAC.
[[File:HAC shrink theory.webp|600px|thumbnail|none]]

An example below.
Right picture: Nominal energy situation (final radius of 2.2Nm).
Left picture: Slightly off nominal energy situation, HAC final radius shrinked to 1.8 Nm and Shuttle was smoothly brought back on the glide.
[[File:HAC shrink example.webp|600px|thumbnail|none]]

'''4) TGTRAN (Transition between TAEM phases)'''

Here is handled the boundaries between the different part of the TAEM and Autoland (Acquisition / HAC / Pre final / Outer Glide Slope / etc)
It works like a big Lego, and it will be easy for example to link it later to the RTLS logic with the phases 4 to 6.
[[File:TAEM iphase.webp|600px|thumbnail|none]]

The S-Turns are also commanded in that function for example.
A sanity check is done to turn away from the HAC. Once the Total Energy is closed to the Nominal one, IPHASE 0 is exited and we go back to the Acquisition logic (IPHASE 1).
[[File:TAEM sturn.webp|600px|thumbnail|none]]

'''5) TGNZC (Nz Commanded)'''

The output for the Pitch AP is done there, under the form of a radial acceleration that will be converted later in to a pitch rate and sent into the AP loop.
All the functions calculated in the TGCOMP will be used there to limit that commanded Nz (NZC).
MIDVALUE function is like a Nasal clamp function.

The first NZC computed is for the altitude error, then it goes through an energy error check, then QBAR, and finally a Max Nz filter to clamp the NZC between -0.5 g and +0.5g.

An example.
If we are low: positive NZC computed to Pitch Up and come back to the reference altitude.
If we are high on energy, a less positive NZC is then outputted to not go too high on energy.
If we are too close to QBAR boundaries, NZC is adjusted to stay away from a hazardous aerodynamical pressure condition.
Finaly, if we are approaching the max radial G's tolerated, the NZC is limited again to avoid breaking the wings.
A quite strong and intricated pitch command loop.
[[File:TGNZC.webp|600px|thumbnail|none]]

''Pitch channel''

The TAEM pitch command loop is based on a commanded radial acceleration (NZC) converted into a pitch rate which is sent to the AP loop for the correct elevon deflection.
Gains and refresh rate depends on TAEM and Autoland phases.
Everything is filtered several times to have some stable outputs.

*Delta Nz commanded is based on the altitude and altitude rate error ( glidepath deviation).
*It goes then through an Energy filter to avoid to be too high or low on energy ( right ladder on MM 305)
*Next filter is a dynamic pressure one to avoid over/underspeed situations.
*Last filter is a Pitch Nz limit (0.5 g) to avoid to break the wings (2g for a 60° of bank turn plus 0.5g for the max pitch commanded ----> 2.5g max for structural considerations)
[[File:TAEM pitchchanne.webp|600px|thumbnail|none]]

'''6) TGSBC (Speedbraked Commanded)'''

It handles the SB logic.
SB setting is fixed to 65° until Subsonic.
In subsonic, position commanded is a function of reference Energy and Qbar errors until final where the logic is blended into a QBAR error only up to 3000 feet.
From there, a fix setting is commanded for Pre-Flare (Highlighted in the second page there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777&start=15]).
That replicates with a great accuracy the original speedbrake logic; fixed setting above Mach 1 (65°) and Energy/Qbar modulation in Subsonic.
Once in final, speedbrakes will control the EAS error (300 kt targeted on Outer Glide Slope).

''Small interesting points''

*Function takes into account the rate limitation depending on the number of hydraulic systems operational.
If more than one system is op, SB opening rate is 5°/s and closing rate is 10°/s
If just one system is op, SB opening and closing rate is 5°/S

*At 3000 feet, there is a first SB retract that takes into account many parameters explained page 2 of that topic: [url]https://forum.flightgear.org/viewtopic.php?f=87&t=38777&start=15[/url]
The complete logic page 73 (4-4) of that Handbook: [https://gandalfddi.z19.web.core.windows.net/Shuttle/JSC-23266%20-%20Approach,%20Landing%20and%20Rollout%20Flight%20Procedures%20Handbook%20-%20Rev%20B%20200505.pdf].
Another parameterwas added, the Altitude Density variation which is a function of the ISA deviation.
High ISA deviation leads to a thiner atmoshpere and a longer flare forecasted, hence a higher SB setting to avoid that over energy situation (and Vice-Versa).

An example there with an ISA deviation of 30 °.
Density altitude is 6129 feet and pressure one is 2264 feet (120ft in addition for every degrees above ISA)
That gives a SB retract of 28° instead of 15° with ISA 0
[[File:SB retract.webp|600px|thumbnail|none]]

*At 500 feet, the windshift between 3000 and 500 feet is taken into account to adjust one last time the SB position.
That is useful in case of gusty conditions with some late wind changes close to the ground.

An example with a stormy and gusty day (up to 30kt).
We lost 15 kt of effective wind since we have past 3000 feet AGL. That is some additional tailwind then and the SB will retract from 23 to 15° to take into account that sudden loss of lift caused by the windshear in order to avoid a hazardous sink rate.
[[File:SB retract 2.webp|600px|thumbnail|none]]

'''7)TGPHIC (Bank commanded)'''

Here is done the bank commanded sent to the AP.
It depends on the Phase we are in.

From Left to Right.
*IPHASE 0 (S-turn): A constant bank is commanded away from the HAC
*IPHASE 1 (HAC acquisition): A bank proportionnal to the delta azimuth (DPSAC) with the WP1 is commanded (2.5 * delta azimuth)
*IPHASE 2 (In HAC): A bank proportionnal to the the HAC cross range and radial velocity is commanded.
*IPHASE 3 (Pre Final): A bank proportionnal to the final axis cross range / cross range variation /cross range integral is commanded.
[[File:TGPHIC.webp|600px|thumbnail|none]]

For the Autoland phases , it is similar to the Pre Final with different Gains.
[[File:TAEM autoland phase.webp|600px|thumbnail|none]]

=== From TAEM to Approach/Autoland handover ===

Landing site threshold coordinates need to be very precise for an autoland.
''They have been adjusted for KSC/VBG/EDW/ZZA/FMI/IPC/HAO/JDG/KEF/YQX/PAR/INN so far''.

At 10000 feet, the TAEM logic is ended and Autoland logic kicks in.
It is fairly similar to the TAEM one, with tighter deadbands and additionnal closed loop guidances for the last part (flare,...)

Three parts: Outer Glideslope tracking up to 2000 feet (blue) / Circular pull up flare to decrease the glideslope from 19°ish up to 1.5° (red) / 1.5° Inner Glide Slope and final flare (green)
[[File:Autoland altitude tracking.webp|600px|thumbnail|none]]

*Outer Glide Slope tracking.
Either 18° or 20° depending of the weight.
Aim point will also slightly modified the downrange and final flare
[[File:Autoland OGS.webp|600px|thumbnail|none]]

*Flare and Inner Glide Slope intercept
At 2000 feet, a 1.3gish pull up is commanded to transition from the steep glideslope to a shallower one (combination of open and closed loops).
An exponential decay to the inner glide slope allows a smooth transition during that pull up maneuver.
Aim is to have at least 5 seconds on the 1.5° slope before the final flare.
[[File:AUtoland flare IGS.webp|600px|thumbnail|none]]

*Final Flare
At 80 feet QFE, another pull up is commanded to decrease the rate of descent.
Aim is to land 2500 feet past the runway threshold.
There are however some dispersions due to winds, ground effect, and some unforseen parameters.
The guidance is quite resilient for a wide range of situations and should be able to bring down safely the Orbiter not far from the targeted touchdown zone.
[[File:Autoland final flare.webp|600px|thumbnail|none]]

More time to watch the sunset while autopilot is on.
[[File:Sunset landing.webp|600px|thumbnail|none]]

[[Category:Space Shuttle documentation]]

Shuttle guidance - Entry guidance algorithm

2026-07-01T17:15:56Z

Celesta: format

{{DEFAULTSORT:Entry guidance algorithm}}
[[File:Spacetripready.png]][[File:Checklistready.png]]
{{Space Shuttle navigation}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

'''Overview'''

A short sum up of the main guidance points explained in the former links

First thing is to convert some Geodetic coordinates into Runway frame coordinates to have an accurate distance to runway threshold through the Heading Alignment Cone; and correct Delta Azimuth to the HAC tangency point.
[[File:Entry frame.webp|600px|thumbnail|none]]

It is done through a targeting routine that will update at every guidance computation frame (1.92s) some parameters.
Main outputs will be Range to Treshold Aimpoint and HAC entry point Azimuth Error.
[[File:Entry functions.webp|600px|thumbnail|none]]

Then will come the entry guidance sequence. A bunch of functions that will output a Commanded Angle of Attack and a Commanded Bank that will then go to the autoPilot loop.
[[File:Entry guidance sequence.webp|600px|thumbnail|none]]

*'''EGSCALEHT''' function generates a constant that will be used to calculate the Reference attitude rate term. It corresponds to the H dot ref term that can be seen in the Entry display
[[File:Entry hdot ref display.webp|600px|thumbnail|none]]
[[File:Entry scale height.webp|600px|thumbnail|none]]

*'''EGINIT''' function resets runway dependant parameters to their nominal values in case of Runway Redesignation.
*'''EGCOMN''' function calculates parameters that will be used during the whole entry (targeted Drag, Total Energy, Hdot reference for Entry display, etc)

*'''ISELECT''' and subsequent functions (EGPEP to EGTRAN) calculate specific parameters depending of the Entry phase.

There are 5 different phases with different transfer logic between them depending of Shuttle Energy (High Energy / Nominal / Low Energy Entries)

IPHASE 1: Preentry opened loop until a drag of 3ft/s² is reached.
IPHASE2: Temperature control (aim there is to avoid to burn the Tiles)
IPHASE3: Equilibrium glide
IPHASE4: Constant Drag (Nominal drag targeted there is 33ft/s² for a smooth deceleration)
IPHASE5: Transition (Below 10000 ft/s, transition from high AOA to lower AOA with flight path increasing).
[[File:Entry guidance sequence logic.webp|600px|thumbnail|none]]

Entry profile is shaped to target an i-loaded constant drag around 16000 ft/s (33ft/s² for a nominal Entry)
[[File:Entry profile.webp|600px|thumbnail|none]]

Those different phases might also be identified through the Entry display layout:
[[File:Entry dps display.webp|800px|thumbnail|none]]

*'''EGALPCMD''' function computes the Angle of Attack to be flown.
Profile that was flown is a 40° AOA until 12000 ft/s ish where the AOA starts to ramp down to reach 15° (Max L/D AOA) at TAEM transition.
[[File:Entry_alpha_commanded.webp|600px|thumbnail|none]]

*'''EGLODVCMD''' calculates the Lift over Drag (L/D) ratio to be flown.
L/D ratio to be flown is based on a reference ratio (L/D zero) which would represent our L/D ratio if we were perfectly on the targeted drag profile.
Corrections for drag and vertical speed errors are added to bring us back on the path in case of deviations.

*'''EGGNSLCT''' calculates f1 and f2 factors (error gains)
[[File:Entry_error_gain.webp|600px|thumbnail|none]]

*'''EGROLCMD''' function converts the commanded L/D ratio into a commanded bank angle to have the correct deceleration. It takes into account the Angle of Attack modulation in case of small drag correction initated by a slight change in AOA.
Reference Bank ( no Drag and Hdot errors) and Commanded Bank are visible in Entry display page.
[[File:Entry_bank_commanded.webp|600px|thumbnail|none]]

'''Some specific point concerning TAL entry'''

To avoid too high temperature during first dive into the atmopshere, Alpha will be increased to 43°
[[File:Entry_tal_alpha.webp|600px|thumbnail|none]]

It decreases the temperature from 3100° to 2800°F during the first part of TAL entry

Once the first pullout is gone ( vertical speed above -400 ft/s), normal alpha schedule and alpha modulation are brought back
[[File:Entry_tal_alpha_mod.webp|600px|thumbnail|none]]

After that huge dive into the atmopshere with a peak in Drag, entry guidance converges towards a more nominal entry trajectory
[[File:Entry_tal_drag_spike.webp|600px|thumbnail|none]]

[[Category:Space Shuttle documentation]]

Space Shuttle

2026-07-01T17:13:27Z

Celesta: /* TAEM/Approach guidance algorithm */

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]] 
 
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===
{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688 ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777 forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|1000px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|1000px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===

[[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

[[Flying the Shuttle - Launch]]

[[Flying the Shuttle - Orbital Operations]]

[[Flying the Shuttle - Entry]]

[[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

[[Flying the Shuttle - Launch And Post Insertion Advanced]]

[[Flying the Shuttle - Deorbit Preparation Advanced]]

[[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]

[[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

[[Flying the Shuttle - Intact Abort Procedures Overview]]

[[Flying the Shuttle - Return To Launch Site RTLS]]

[[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Educational Links / Shuttle technical files ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

== Videos ==

A compilation of in FG Sim videos about the Space Shuttle

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

== Mission reports ==

A compilation of Space Shuttle stories / mission reports.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

[[Category:Space Shuttle documentation]]

Space Shuttle

2026-07-01T17:13:05Z

Celesta: /* TAEM/Approach guidance algorithm */

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]] 
 
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===
{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688|ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777|forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|1000px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|1000px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===

[[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

[[Flying the Shuttle - Launch]]

[[Flying the Shuttle - Orbital Operations]]

[[Flying the Shuttle - Entry]]

[[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

[[Flying the Shuttle - Launch And Post Insertion Advanced]]

[[Flying the Shuttle - Deorbit Preparation Advanced]]

[[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]

[[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

[[Flying the Shuttle - Intact Abort Procedures Overview]]

[[Flying the Shuttle - Return To Launch Site RTLS]]

[[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Educational Links / Shuttle technical files ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

== Videos ==

A compilation of in FG Sim videos about the Space Shuttle

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

== Mission reports ==

A compilation of Space Shuttle stories / mission reports.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

[[Category:Space Shuttle documentation]]

Help:Templates

2026-07-01T16:58:56Z

Celesta: /* Advanced template help */ replace css link

{{Wiki help navbar}}

'''Templates''' are pages that can contain complex pieces of wiki markup that can be reused on other pages with relative ease. On this help page we will go through what a template is, how to find them and use them as well as editing existing and creating new templates. Finally we will have a quick look on some of the things that can be used in more advanced templates.

== Basics ==
=== What is a template? ===
In simple terms you are adding another page, or rather contents from it, into the page you are editing when you use a template. This is called transclusion. While the wiki has a special template namespace, indicated by a preceding ''Template:'' in the page title, any page can be used as a template.

If a template for example is named ''Template:Helloworld'' and contains:
Hello World!

Typing the following on a page would copy that content to the page you are editing. Note that the first character is not case sensitive.
<pre>{{helloworld}}</pre>

However, the templates can in addition to MediaWiki, html and style sheet markup also use a wide range of special functions to do a lot, lot more.

=== Different types of templates ===
There are several types of templates, some of the more visible are the messagebox templates, infobox templates and navigation box templates, but there are also many other kinds of templates. The following is just some few of the different kinds of templates:

;Messagebox templates: Messagebox templates are often found on the top of pages and sometimes on the top of sections. In rare cases they can be found in the text. Their purpose is to give the reader or potential editors information.

;Infobox templates: Infobox templates are nearly always found at the top right of pages. They are literally a box of information on a subject, often about the subject of the page.

;Navigation templates: Navigation templates are usually found at the top right or bottom of a page. They are meant to help the reader navigate between pages on a similar context, for example a series of articles or articles about FlightGear aricraft by the same manufacturer.

;Maintenace templates: Maintenance templates are nearly without exception messagebox templates. Their purpose is to aid the maintenance of the wiki and to point out things that need to be improved.

;Utility templates: Utility templates are often small, but very useful templates.

;Inline templates: Templates that can be used within sentences and flowing text.

== Using templates ==
=== Finding templates ===
There are several ways to find a template to use:

;Using categories: Most templates can be found in [[:Category:Templates]] and its subcategories.

;Using lists of templates: There is also lists of some of the templates, see [[Help:Gallery of messagebox templates]] and [[Help:Gallery of infobox templates]].

;Finding templates through a page they are used within: Another way to find templates is when you find a page using templates you are interested in using. If you open that page for editing you will on the very bottom of the page find a list of the templates used by that page and the templates those templates are using.

;Finding templates similar to another one: Links to similar templates can often be found at the bottom of a templates documentation.

;Searching for contents of a template: As a last resort you can search for using possible contents of a template, typing "Template:<whatever>" in the search box. Instead of going straight to the page as you would do if you would knew its name, you will get to a page of search results with pages that might contain the template you are looking for.

=== Template parameters ===
Most templates take arguments, called parameters. Some templates do not. Some parameters may be optional, some mandatory. Mandatory parameters must always be used, while optional parameters doesn't have to. There are also unnamed and named parameters. Unnamed parameters are sometimes called numbered parameters as they have to be used in a certain order and ar numbered within the template source. Named parameters are always used in key-value pairs, like for example <tt>month={{CURRENTMONTHNAME}} {{CURRENTYEAR}}</tt>.

In some of the template documentation the following convention is used to illustrate how parameters can be used:

<nowiki>{{</nowiki>'''template name'''<nowiki>|</nowiki>mandatory unnamed parameter<nowiki>|</nowiki>''optional unnamed parameter'' <nowiki>|</nowiki>mandatory named parameter= <nowiki>|</nowiki>''optional named parameter=''<nowiki>}}</nowiki>

In most cases it is possible to use any kind of wiki markup in the parameters, for example wiki links.

As said above the unnamed parameters must be used in a certain order, though they can if not mandatory be left empty. Take for example the following template:
<nowiki>{{</nowiki>'''template'''<nowiki>|</nowiki>''parameter 1''<nowiki>|</nowiki>''parameter 2''<nowiki>|</nowiki>''parameter 3''<nowiki>|</nowiki>''parameter 4''<nowiki>|</nowiki><nowiki>}}</nowiki>

Usually the most commonly used and/or mandatory parameters are the first one or ones, but if we just as an example would be to use only the last two parameters we would have to do like below:
<nowiki>{{template|||parameter 3|parameter 4}}</nowiki>

=== Template documentation ===
When you know what template you want to use, you are recommended take a look at its documentation, unless you have already done that earlier. You will find the documentation on the template's page. The documentation describes the purpose of the template and how to use it, as well as link to related templates. Unfortunately not all templates are documented.

Many templates have a ''Known issues'' section in the template documentation. Some templates have innate peculiarities that can not be fixed, but can be worked around. One of the more common issues is that a few characters that are used to either build tables or are used within templates will break a template, those characters are the equal sign <tt>=</tt> and a vertical stroke and some combinations of it, <tt>|</tt>, <tt>||</tt> and <tt>|-</tt>. The usual workaround are to use the templates {{tl|{{=}}}}, {{tl|!}}, {{tl|!!}} and {{tl|!-}}.

The template documentation contains a list of the parameters the template uses that can be copied and pasted to the page you are editing, sometimes even with some of the parameters filled in, like for example this template:

<nowiki>{{</nowiki>'''splitapart'''<nowiki>|</nowiki>''Discussion page section'' <nowiki>|</nowiki>''date={{CURRENTMONTHNAME}} {{CURRENTYEAR}}''<nowiki>}}</nowiki>

In the template documentation there is also a list of the parameters and how they are supposed to be used and there are often examples to illustrate the different ways the parameters can be used.

== Creating new templates ==
=== Choosing a good name ===
Consider giving the template a meaningful name. Usually one would try to only have the initial character upper case. If you are mimicking a template on another wiki, using its name might be a good idea. If the template will be used very often it might actually be a good idea to use a very short name or an abbreviation, but proper categorisation and documentation will then be even more important. Do note that parameter names are case sensitive except for the first character.

=== Search first ===
To create a new template, please start by using the search function. This way you will find if there already is a template with that name or if there is one with a very similar name. If there is no template with that name you will be presented with the option to create that page. Click on the red link to open up a edit window.

=== Things to include ===
Two important things to add to your template is template documentation, preferably using {{tl|informative template}} and if possible to put the template in a more fitting category than [[:Category:Templates]].

Unless it is a very simple template it can be a good thing to start by writing the documentation as this might help you figuring out the last few things in what you want the template to do and how you want it to do that, and then more or less use the documentation as reference when typing the template itself.

=== Preview often ===
Do remember that you can, and should use the preview button now and then, or at least one before saving, in order to catch any errors before saving. One way of debugging a template is to add obvious clues as to where in a template something got wrong, for example 1?, 2?... This can be really helpful in some cases, though in other cases it will be obvious. Some common mistakes are the same ones as on article pages: Missing end markers in tables and missing end tags or end tags with missing slashes.

While the template always can be fixed if there are errors it is better to have an extra preview than an extra edit. Do note that the template will be lost if you do not save it.

== Editing templates ==
Editing a template is often as easy as editing a normal wiki page. Lets say you want to edit a template with the name ''what you always wanted to know''. Either search for the template using the template namespace like ''Template:What you always wanted to know'' or click on a link to get you there.

If the template code is very complex, it might be an idea to resist tampering with it, even though the edits can easily be undone.

Always try to add documentation to templates missing that, preferably using {{tl|informative template}}.

=== Passing unnamed parameters ===
Passing parameters to templates make them a lot more useful. Unnamed parameters can be used in the order they are passed, in essence <tt><nowiki>{{{1}}}</nowiki></tt>, <tt><nowiki>{{{2}}}</nowiki></tt> etc. Consider the following template, ''Template:Hello'':
<pre>Hello, {{{1|}}}{{{2|stranger}}}!</pre>

Its usage:
<nowiki>{{</nowiki>'''hello'''<nowiki>|</nowiki>''title''<nowiki>|</nowiki>''name''<nowiki>}}</nowiki>

And an example:
<pre>{{hello|Dr.|Falken}}</pre>
Hello, Dr. Falken!

=== Default values ===
You might wonder what that vertical stroke and the text following, <tt><nowiki>{{{</nowiki>1'''|'''<nowiki>}}}{{{</nowiki>2'''|stranger'''<nowiki>}}}</nowiki></tt>, in ''Template:Hello'' does. Most of you will already have guessed that they are default values. Having at least an ''empty'' default value is a good practice, as templates otherwise will break when passed an empty parameter. Here is what happens when the above template is used without parameters:
<pre>{{hello}}</pre>
Hello, stranger!

And here is what would happen if it would be used without parameters and did not have default values:

<nowiki>Hello, {{{1}}}{{{2}}}!</nowiki>

=== Passing named parameters ===
While using a template with named parameters can be a bit more of typing, they are not that much extra typing when editing a template. They are however practical some other ways, they can be passed to a template in any order and, more important, they are named (as in not numbered). That last thing makes them immensely more useful in complex templates.

Using them in a template are not that different than unnamed parameters. Using the above template, but with named parameters, we could instead type:
<pre>Hello, {{{title|}}}{{{name|stranger}}}!</pre>

Its usage:
<nowiki>{{</nowiki>'''hello''' <nowiki>|</nowiki>''title='' <nowiki>|</nowiki>''name=''<nowiki>}}</nowiki>

And an example:
<pre>{{hello |title=Dr. |name=Falken}}</pre>
Hello, Dr. Falken!

=== To include or not include ===
Sometimes you have content in a template that you do not want to be transcluded or that you want to have transcluded but not included in the template. Consider for example the template documentation, of course you would not want it to be on every page the template is used on, also, sometimes you want a template to add a category to the page it is used on, but not to the template itself. This can be done using the <tt><nowiki><noinclude></nowiki></tt> and <tt><nowiki><includeonly></nowiki></tt> tags.

To go back to the ''Template:Hello'' template, the below example shows how ''Category:Pages that says hello'' is added to the page that uses the template but not to the template and how the documentation and ''Category:Hello templates'' is added to the template, but not the page it will be used on. Note that both the <tt><nowiki><includeonly></nowiki></tt> and <tt><nowiki><noinclude></nowiki></tt> tags are right behind the text of the template, as a having a line break would cause a line break when the template is used.

Here is the full ''Template:Hello''. Do not worry about typing all that text, {{tl|informative template}} is one of the templates with pre-filled examples you can copy and paste into the template you are editing.

<nowiki>Hello, {{{1|}}}{{{2|stranger}}}!<includeonly>[[Category:Pages that says hello]]</includeonly><noinclude>
{{Informative template|1=
__NOTOC__
== Goal ==
This template can be used to show a friendly hello.

Adding this template to a page will automatically add that page to [[:Category:Pages that says hello]].

== Usage ==
<nowiki>{{</nowiki>'''hello'''<nowiki>|</nowiki>''title''<nowiki>|</nowiki>''name''<nowiki>}}</nowiki>

;parameter: Optional title, for example "<tt>Dr.</tt>"

;parameter: Optional name, defaults to "<tt>stranger</tt>"

== Examples ==
<pre>{{hello|Dr.|Falken}}</pre>
Hello, Dr. Falken!

<pre>{{hello}}</pre>
Hello, stranger!

}}

[[Category:Hello templates]]
</noinclude></nowiki>

=== Category suppression ===
Sometimes it is helpful if a template suppresses categorisation and only categorizes some of the pages it is put on. There is a few templates that can be used for that in [[:Category:Namespace templates]]. Most of them uses the namespace of the page the template is put on. For example '''''Help talk:'''Templates'' is in the ''Help talk'' namespace.

One of those templates is {{tl|main other}}:
<nowiki>{{</nowiki>'''main other'''<nowiki>|</nowiki>''text if main''<nowiki>|</nowiki>''text if other'' <nowiki>|</nowiki>''demospace=''<nowiki>}}</nowiki>

If the template is put on a page in the main namespace, the the namespace that articles are in, '''text if main''' text is used. Otherwise '''text if other''' is used. Both can be overridden if '''demospace''' is set as '''demospace = other''' when in the main namespace and '''demospace = main''' when in any other.

If a category link is used in '''text if main''' like below the page will only be categorized if the template is put in the main namespace. Note that all the parameters are optional.

<nowiki>
...
}}

{{main other|[[Category:Hello templates]]}}
</noinclude></nowiki>

Apart from '''demospace''' some templates will have a '''nocat''' parameter that when not empty or set as '''nocat = yes''' will suppress categorisation altogether.

== Translating templates ==
Templates are translated in a different way than [[Help:Translate|normal articles]]. Instead of creating another page for each translation, all translations are written within one template. To do that one can use the {{tl|LangSwitch}} template, for example like below.

<nowiki>[http://{{LangSwitch
| en = 
en
| de = 
de
| fr = 
fr
}}.wikipedia.org Wikipedia]</nowiki>

<nowiki>{{LangSwitch
| en = 
{{ The template with English contents }}
| de = 
{{ The template with German contents }}
| fr = 
{{ The template with French contents }}
}}</nowiki>

{{note|Many templates use tables and have to start from the beginning of the line, like in the above example.}}
{{note|Inserting blank lines or spaces will usually cause unintended changes to the way the template are rendered.}}

The {{tl|LangSwitch}} template uses the two letter language code present in all but the English page titles. If none of the languages that have been translated to is found, a template have not yet been translated to that language and the English text will be used instead, provided it is available.

When checking out that the language versions render as they should you can add a '''lang''' parameter to the template for debugging purposes. Remember to remove it before saving or the template will only be showed in that language. The below example would show the French (fr) version of the template:

<nowiki>{{LangSwitch
...
| lang = fr }}</nowiki>

== Advanced template editing ==
The templates can contain some very advanced and often complex code, but even easier code can do great things to make life easier for you as an editor using it later.

While this page will not go into details, there is a few secrets to more advanced templates:
;Tables: Wiki tables are tricky to understand, but can do a lot for any kind of box template and small layouts.

;Magic words: Magic words are mostly all uppercase and many of them at first look like templates. Some of them are for example <tt><nowiki>{{CURRENTMONTHNAME}}</nowiki></tt> and <tt><nowiki>__NOTOC__</nowiki></tt>.

;Parser functions: Parser functions allow more or less regular programming with conditionals, switches, string formatting etc. One of them is <tt>#if</tt>, <tt><nowiki>{{</nowiki>'''#if:''' ''string'' | ''passed if non-empty'' | ''passed if empty'' <nowiki>}}</nowiki></tt>.

;HTML: It might seem a bit funny to mention it, but sometimes you forget that you can use (some) html tags in a MediaWiki wiki.

;Cascading style sheets: Like magic words and parser functions can do magic for the functionality of a template CSS can do magic for its appearance.

A good hint on getting more readable template source is that well placed HTML comments (<tt></tt>) will help a lot.

== External links ==
* {{mediawiki|Help:Templates|MediaWiki template help}}

=== Advanced template help ===
* [http://meta.wikimedia.org/wiki/Meta:About_Meta Mediawiki Meta]
** [http://meta.wikimedia.org/wiki/Help:Template Meta:Help:Template]
** [http://meta.wikimedia.org/wiki/Help:Advanced_templates Meta:Help:Advanced templates]
** [http://meta.wikimedia.org/wiki/Help:Table Meta:Help:Table]
* {{mediawiki|Project:About}}
** {{mediawiki|Help:Tables}}
** {{mediawiki|Help:Magic words}}
** {{mediawiki|Help:Extension:ParserFunctions}}
* [https://www.w3.org/Style/CSS/learning Cascading Style Sheets (CSS)]

[[Category:Help]]

[[fr:Help:Templates]]

Help:Main navigation elements

2026-07-01T16:55:31Z

Celesta: Removed redirect to Fr/Aide:principaux éléments de navigation wiki

{{Wiki help navbar}}

Three '''main navigation elements''' are available on each page of the FlightGear wiki (from top to bottom):

*The ''user links'' at the top right. These are linked to your account (if you have one)

* The ''page tabs'' above the page content. These are, for example, links to the discussion page and the revision history.
*The ''sidebar'' at the top left, links to various tools and links to other language versions of a page.

Although there are two ways to view wiki pages, the ''desktop view'' and the ''mobile view'', we will explain the ''desktop view'' here because the ''mobile view'' hides many features for the sake of simplicity. Features are described as they appear with the default skin.

{{TOC limit|2}}

==User links==
[[File:FlightGear wiki user links.png|frame|none|View of user links for a logged-in user]]

If you have an account and are logged in, the user links at the very top right are associated with your user account:

:;your user page
::Your user page, where you are encouraged to describe who you are and what ambitions you have on the wiki. You can also add sub-pages to your user page with, for example, drafts and other wiki projects.
:;Talk
::Your user talk page, where other users may be able to contact you. If your talk page has been edited by someone else, you will receive a notification the next time you log in or load another wiki page. You can also optionally configure your preferences to receive an email if your talk page has been edited.
:;Preferences
:: Your wiki preferences, where you can adjust and customize certain settings.
:;Watchlist
::Your [[Help:Tracking changes|watchlist]], which lists changes on pages you have "starred" and are watching.
:;Contributions
::A summary of your contributions and uploads to the wiki.
:;Log out
::By which you log out of your account.

==Page tabs==
[[File:FlightGear wiki page tabs.png|frame|none|The page tabs for a logged-in administrator (who can also delete and protect pages)]]

At the top of the page content, there is a set of tabs:

:;An article or page tab
::To view the article if you are on another tab or to go directly to the page if you have been redirected. The page tab also gives an indication of the type of page you are on.
:;a talk tab
::With the talk page for a wiki page or a user

;Read tab
:With exactly the same function as the page tab
;Edit or edit wiki code tab
: Which will allow you to edit a page on the wiki when you are logged in or see the page source if you are not.
;History tab
:Which will display the [[Help:Tracking changes|history]] of changes to a wiki page.
;Favorite tab (star)
:This will add or remove a page to or from your watchlist.
;More tab
:With a few extra functions, including a function to move pages (essentially renaming them). Wiki administrators also have a protection function and a deletion function.
:
==Sidebar==
[[File:FlightGear wiki sidebar.png|frame|right|The sidebar]]

At the top left is the sidebar with:

:;Navigation links
::To certain pages deemed important enough to be linked from every page:
::;The wiki home page
:::Where you end up by going to [http://wiki.flightgear.org](http://wiki.flightgear.org)
::; Recent changes
:::Listing the [[Help:Tracking changes#Recent changes|latest changes]] on the wiki
::;A random article
::;The village pump
:::The [[FlightGear wiki:Village pump|village pump]] is the wiki talk page not linked to a particular page or user.
::;The summary of help pages
::; The portal pages
:;FlightGear WEB sites
::*The home page [http://flightgear.org](http://flightgear.org)
::* The forum [http://forum.flightgear.org](http://forum.flightgear.org)
::* The [[Mailing lists|mailing lists]] where developers coordinate
::*The [[https://sourceforge.net/p/flightgear/_list/git](https://sourceforge.net/p/flightgear/_list/git) source code repository] on SourceForge
::*The {{tickets|bug tracker}} on SourceForge
::*The [[FlightGear Scenery Database|scenery database]] FlightGear which contains landmarks, such as larger buildings, masts, and wind turbines
::*The [[FlightGear livery database|livery database]] with many additional liveries for popular aircraft
:;Toolbox
::Slightly dependent on the type of page you are viewing
::*A summary of pages linked to the page you are viewing
::*A summary of changes linked to the page you are viewing
::*The upload wizard
::*A set of special pages, with information on pages, categories, files, and users
::* A printable version of the page viewed
::*A link to the current revision of the page you are viewing
::*Information on the page you are viewing
:;Language links
::To versions of the page in other languages

==Category links==
[[File:FlightGear wiki category link footer.png|frame|right|Category link at the bottom of a wiki page]]

Categories will make it easier to navigate between related pages or images. If a page has been categorized, it will have links to the associated category pages at the bottom of the page. Category pages list the categories, pages, and files in that category and will contain links to any parent categories.

[[Category:Aide|Navigation]]
[[Category:Help|Translate]]

[[en:Help:Main navigation elements]]
[[fr:Aide:Main navigation elements]]

Fr/Aide:principaux éléments de navigation wiki

2026-07-01T16:53:41Z

Celesta: remove dead link

{{Wiki help navbarFr}}

Trois '''éléments de navigation principaux''' sont disponibles sur chaque page du wiki FlightGear (de haut en bas) :

*Les ''liens de l'utilisateur'' en haut à droite. Ceux-ci sont liés à votre compte (si vous en possédez un)
* Les ''onglets de page'' au-dessus du contenu de la page. Il s'agit par exemple de liens vers la page de discussion et l'historique des révisions.
*La ''barre latérale'' en haut à gauche, des liens vers divers outils et des liens vers d'autres versions linguistiques d'une page.

Bien qu'il existe deux façons d'afficher les pages wiki, la v''ue poste de travail'' et la ''vue sur mobile'', nous allons exposer ici la vue ''poste de travail'' car la ''vue sur mobile'' masque de nombreuses fonctionnalités par souci de simplicité. Les fonctionnalités sont décrites telles qu'elles apparaissent avec l'habillage par défaut.

{{TOC limit|2}}

==Liens utilisateurs==
[[File:FlightGear wiki user links.png|frame|none|Vue des liens utilisateur pour un utilisateur connecté]]

Si vous avez un compte et que vous êtes connecté, les liens utilisateurs tout en haut à droite sont associés à votre compte utilisateur :

:;votre page utilisateur
::Votre page utilisateur, où vous êtes encouragé à décrire qui vous êtes et quelles ambitions vous avez sur le wiki. Vous pouvez également ajouter des sous-pages à votre page utilisateur avec par exemple des brouillons et d'autres projets wiki.
:;Parler
::Votre page de discussion d'utilisateur, où d'autres utilisateurs peuvent être en mesure de prendre contact avec vous. Si votre page de discussion a été modifiée par quelqu'un d'autre, vous recevrez un avis la prochaine fois que vous vous connecterez ou chargerez une autre page wiki. Vous pouvez également éventuellement configurer vos préférences afin de recevoir un e-mail si votre page de discussion a été modifiée.
:;Préférences
:: Vos préférences wiki, où vous pouvez ajuster et personnaliser certains paramètres.
:;Liste de surveillance
::Votre [[Help:Tracking changes|liste de surveillance]], qui répertorie les changements sur les pages que vous avez "mises en vedette" et que vous regardez.
:;Contributions
::Un résumé de vos contributions et téléchargements sur le wiki.
:;Déconnexion
::Par lequel vous vous déconnectez de votre compte.

==Onglets des pages==
[[File:FlightGear wiki page tabs.png|frame|none|Les onglets de page pour un administrateur connecté (qui peut également supprimer et protéger des pages)]]

En haut du contenu de la page, il y a un ensemble d'onglets :

:;Un onglet article ou page
::Pour consulter l'article si vous êtes sur un autre onglet ou pour accéder directement à la page si vous avez été redirigé. L'onglet de la page donne également une indication sur le type de page sur laquelle vous vous trouvez.
:;un onglet discussion
::Avec la page de discussion pour une page wiki ou un utilisateur

;Onglet lire
:Avec exactement la même fonction que l'onglet de la page
;Onglet modifier ou modifier le code wiki
: Ce qui vous permettra de modifier une page sur le wiki lorsque vous êtes connecté ou de voir la source de la page si ce n'est pas le cas.
;Onglet historique
:Ce qui affichera l'[[Help:Tracking changes|historique]] des modifications d'une page wiki.
;Onglet favori (étoile)
:Cela ajoutera ou supprimera une page à ou de votre liste de surveillance.
;Ongley plus
:Avec quelques fonctions en plus, notamment une fonction pour déplacer les pages (essentiellement les renommer). Les administrateurs du wiki ont également une fonction de protection et une fonction de suppression.
:
==Barre latérale==
[[File:FlightGear wiki sidebar.png|frame|right|The sidebar]]

En haut à gauche se trouve la barre latérale avec :

:;Les liens de navigation
::Vers certaines pages jugées suffisamment importantes pour être liées à partir de chaque page :
::;La page d'accueil du wiki
:::Où vous vous retrouvez en allant à http://wiki.flightgear.org
::; Les modifications récentes
:::Répertorier les [[Help:Tracking changes#Recent changes|dernières modifications]] sur le wiki
::;A random article
::;Le village pump
:::Le [[FlightGear wiki:Village pump|village pump]] est la page de discussion wiki non liée à une page ou à un utilisateur particulier.
::;Le résumé des pages d'aide
::; Les pages du portail
:;Sites WEB FlightGear
::*La page d'accueil http://flightgear.org
::* Le forum http://forum.flightgear.org
::* Les [[Mailing lists|listes de diffusion]] où se coordonnent les développeurs
::*Le [https://sourceforge.net/p/flightgear/_list/git dépôt du code source] sur SourcceForge
::*Le {{tickets|traqueur de bogues}} sur SourcceForge
::*La [[FlightGear Scenery Database|base de données des scènes]] FlightGear qui contient des points de repère, comme par exemple des bâtiments plus grands, des mâts et des éoliennes
::*La [[FlightGear livery database|base de données de livrées]] avec de nombreuses livrées supplémentaires pour les avions populaires
:;Boite à outils
::Légèrement dépendant du type de page que vous consultez
::*Un résumé des pages liées à la page que vous consultez
::*Un résumé des modifications liées à la page que vous consultez
::*L'assistant de téléchargement
::*Un ensemble de pages spéciales, avec des informations sur les pages, les catégories, les fichiers et les utilisateurs
::* Une version imprimable de la page consultée
::*Un lien vers la révision actuelle de la page que vous consultez.
::*Informations sur la page que vous consultez
:;Liens vers les langages
::Vers les versions de la page dans d'autres langues

==Liens vers les catégories==
[[File:FlightGear wiki category link footer.png|frame|right|Category link at the bottom of a wiki page]]

Les catégories faciliteront la navigation entre les pages ou les images associées. Si une page a été catégorisée, elle aura des liens vers les pages de catégorie associées au bas de la page. Les pages de catégorie répertorient les catégories, les pages et les fichiers de cette catégorie et contiendront des liens vers toutes les catégories parentes.

[[Category:Aide|Navigation]]
[[Category:Help|Translate]]

[[en:Help:Main navigation elements]]
[[fr:Aide:Main navigation elements]]

Space Shuttle

2026-07-01T16:50:20Z

Celesta: /* Entry guidance algorithm */ remove first-person pronouns

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]] 
 
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===
{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''https://ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''https://ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|1000px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|1000px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===

[[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

[[Flying the Shuttle - Launch]]

[[Flying the Shuttle - Orbital Operations]]

[[Flying the Shuttle - Entry]]

[[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

[[Flying the Shuttle - Launch And Post Insertion Advanced]]

[[Flying the Shuttle - Deorbit Preparation Advanced]]

[[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]

[[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

[[Flying the Shuttle - Intact Abort Procedures Overview]]

[[Flying the Shuttle - Return To Launch Site RTLS]]

[[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Educational Links / Shuttle technical files ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

== Videos ==

A compilation of in FG Sim videos about the Space Shuttle

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

== Mission reports ==

A compilation of Space Shuttle stories / mission reports.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

[[Category:Space Shuttle documentation]]

Community

2026-06-29T04:30:02Z

Celesta: Redirected page to Category:Community

#redirect [[:Category:Community]]

FlightGear China

2026-06-29T04:29:04Z

Celesta:

{{User
|name = FlightGear China
|age = {{#expr: {{CURRENTYEAR}} - 2016 - ({{CURRENTMONTH}} < 8)}} (Founded August 2016)
|website = https://www.fgprc.org.cn https://www.fgprc.org
}}

'''FlightGear China''' ('''FGPRC''') is a organization for FlightGear users and fans in China.

[[File:FGPRC logo.png|thumbnail]]

== Services ==
MPMap: https://mpmap.fgprc.org 

MPMap (hosted in China): https://mpmap.fgprc.org.cn

== MP Server ==
We have an MP server network that is not yet connected to the official FlightGear MPServer Network.

* mpcn01.fgprc.org (Located in Beijing, China) (Not available as of December 2023 due to server cost)
* mpcn02.fgprc.org (Located in Singapore)

== Members ==
As of Apr 2026, we have 251 members in our QQ group.

== Links ==
* [https://www.fgprc.org.cn Official Website (Chinese)]
* [http://www.fgprc.org Official Website (English)]
* [https://github.com/fgprc-flightgearchina Github]

[[Category:Community|China]]

FlightGear China

2026-06-29T04:28:51Z

Celesta: age template

{{User
|name = FlightGear China
|age = {{#expr: {{CURRENTYEAR}} - 2016 - ({{CURRENTMONTH}} < 8)}} (Founded August 2016)
|website = https://www.fgprc.org.cn https://www.fgprc.org
}}

'''FlightGear China''' ('''FGPRC''') is a organization for FlightGear users and fans in China.

[[File:FGPRC logo.png|thumbnail]]

== Services ==
MPMap: https://mpmap.fgprc.org 

MPMap (hosted in China): https://mpmap.fgprc.org.cn

== MP Server ==
We have an MP server network that is not yet connected to the official FlightGear MPServer Network.

* mpcn01.fgprc.org (Located in Beijing, China) (Not available as of December 2023 due to server cost)
* mpcn02.fgprc.org (Located in Singapore)

== Members ==
As of Apr 2026, we have 251 members in our QQ group.

== Links ==
[https://www.fgprc.org.cn Official Website (Chinese)]
[http://www.fgprc.org Official Website (English)]
[https://github.com/fgprc-flightgearchina Github]

[[Category:Community|China]]

Operation Red Flag

2026-06-29T04:27:46Z

Celesta: age template

{{User
|name = Operation Red Flag
|age = {{#expr: {{CURRENTYEAR}} - 2015 - ({{CURRENTMONTH}} < 11)}} (created Nov 2015)
|website = http://opredflag.com/
}}
[[File:OPRF.png|thumbnail]]
== Introduction ==
Operation Red Flag (also known as OPRF and KSUU Crew), which is a community of pilots who share the interest of military aviation and related topics that trains regularly in the surrounding area of [[Nellis_Air_Force_Base|KLSV]] and KXTA, and organize monthly big events focused on realistic military operations. Members are interested in aerial games of strategy using military aircraft. While we understand that FG is not a flight simulator geared toward war or aggression, we appreciate developing the flight, strategy, and decision-making skills that are honed through these types of challenges. The aim of Operation Red Flag (KSUU Crew) efforts is to ensure that military aviation novices and aficionados have a space to collaborate, engage with each-other, and use military aviation assets in tactical environments WITHOUT negatively impacting the FG experience of those who are not so-inclined.
Link for information: [[Virtual_airlines#Virtual_air_forces| here]] (Scroll down to Virtual Air Forces, click on Op Red Flag)

As of Apr 2026, we have 491 members on our Discord server.

== Forum topic ==
* {{forum link|title=Operation Red Flag (KSUU Crew)|t=28057}}
[[Category:Community]]

== External links ==
* [https://discord.gg/ptVapkE Discord server]

Release plan

2026-06-29T04:11:27Z

Celesta: /* Related content */

{{GitStatus}}

The '''release plan''' is the process by which a new version of [[FlightGear]] is released. The release plan is actually a continual work-in-progress, and is refined with every new release and how much available resource and interest there is.

[[File:ReleasePlan.jpg|thumb|250px|The original release plan.]]
FlightGear has had multiple release plans over [[FlightGear History|history]].
* Originally, releases were sporadic, irregular and took many months of manual preparation.
* Subsequently a release plan was developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during [[LinuxTag]] 2011.
* A more regular plan was proposed by Torsten Dreyer after the 3.6 release was [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|cancelled]].
* Currently "Long Term Support" (LTS) releases are generated every ~24 months, with intermittent "preview" releases between them which receive less testing and support.

To suggest improvements and/or changes to the release plan, it is recommended to get in touch via the [[mailing list]]. Improvements can be based on the [[Release plan/Lessons learned|lessons learned]] from previous releases. However, do not underestimate the amount of effort go create a new release! Most of the burden falls on a few people.

== General release concept ==
At any given time there are two release "stream":
* A stable release stream. This is a stable release to which bug fixes are applied, and will be active for up to two years. Most users and aircraft developers use this release. Currently {{current release|cr}}.
* A "preview" release, based on the development branch "next". This is for those interested in the latest developments. There is not currently a preview release.

== Version numbers ==
FlightGear version numbers consist of three digits, separated by dots:

* '''Year''' (2020.1.0): The year the version was released.
* '''Number''' (2020.1.0): Which release of the year the version is.
* '''Revision''' (2020.1.0): The patch revision on that release.

{{note|In general, release are referred to by their first two digits (e.g., 2020.3). However, when filing a bug report or debugging problems, it is a good idea to give the full release number.}}

== Version files ==
; FGData: {{fgdata file|version}}
; SimGear: {{simgear file|simgear-version}}
; FlightGear: {{flightgear file|flightgear-version}}

== Bug tracker ==
The bug tracker can be seen at [https://gitlab.com/flightgear/flightgear/-/work_items Work items] and [https://gitlab.com/flightgear/flightgear/-/boards Issue boards].


== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.


== Wiki articles that should be updated ==

See: [[:Category:Articles to be updated for each release]]

== Related content ==
* [[Release: Airport Selection Criteria]]

[[Category:Core developer documentation]]
[[Category:FlightGear]]
[[Category:Release plans]]

[[fr:Release plan]]

FlightGear history

2026-06-29T04:09:45Z

Celesta: /* Version 3.8.0/2016.1.0 */

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 

"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.'' 
''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 

Rather than start entirely from scratch, FlightGear developers made use of the [[LaRCsim]] flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Version 2018.1 "Honolulu" (2018) ==
Released in April 2018, version 2018.1 was the first major update in the 2018 release cycle. This version focused on environmental realism and significant improvements to the YASim flight dynamics model (FDM), including support for multiple wing sections to model variable wing geometry. The "Honolulu" release featured PHNL as the default airport and introduced active volcanoes such as Kilauea and Etna, which integrated environmental physics by generating increased turbulence in their vicinity. The [[Atmospheric light scattering|ALS (Atmospheric Light Scattering)]] renderer was also updated with extra volumetric vegetation layers for denser undergrowth.

== Version 2019.1 (2019) ==
Version 2019.1, released in March 2019, introduced the "Compositor," an experimental XML-configurable rendering framework designed to replace legacy hard-coded rendering paths. This framework enabled advanced post-processing effects and Cascaded Shadow Mapping (CSM) for more realistic environmental shadows. Other technical advancements included the introduction of a DDS Texture Cache to speed up loading times and the implementation of 8.33 kHz radio frequency spacing for aircraft like the [[Boeing 777]] to comply with modern European airspace requirements.

== Version 2020.1 and 2020.3 LTS (2020) ==
The 2020 cycle saw the release of 2020.1 in May and the Long Term Support (LTS) version, 2020.3, in October. This era was marked by a shift toward data integrity, particularly in the JSBSim FDM, where gyros were updated to measure rotation rates rather than rotational accelerations to better match physical reality. Graphical performance was enhanced through instanced-based rendering for OpenStreetMap (OSM) buildings, which was later integrated into the [[TerraSync]] system (v2020.3.7) for global coverage. The release also featured expanded aircraft carrier support with new launcher options for takeoff and approach positions.

== Version 2024.1 (2025-2026) ==
Replacing the 2020.3 LTS, version 2024.1 (officially released in February 2025 as v2024.1.1) represents a major technological pivot for the project. Key highlights include:

* [[VR]] Support: Preliminary integration of VR headsets using the OpenXR standard.

* [[World Scenery 3.0]] (WS3.0): A preview of a new Quadtree-based scenery system utilizing Virtual Planet Builder, providing higher frame rates and lower memory usage through multiple levels of detail.

* Dynamic Lighting and Shadows: Real-time dynamic shadows and lighting were added to the core rendering engine.

* Climate Modeling: The legacy season selection was replaced with a holistic climate model calculating environmental factors like snow lines and ocean temperatures dynamically.

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| Oct 13, 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|-
| Jul 26, 2021 || 2020.3.10
|-
| Jul 29, 2021 || 2020.3.11
|-
|Feb 6, 2022
|2020.3.12
|-
|Mar 30, 2022
|2020.3.13
|-
|Sep 27, 2022
|2020.3.14
|-
|Oct 12, 2022
|2020.3.15
|-
|Oct 20, 2022
|2020.3.16
|-
|Sep 22, 2022
|2020.3.17
|-
|Mar 21, 2023
|2020.3.18
|-
|Feb 27, 2025
|2024.1.1
|-
|Sep 18, 2025
|2024.1.2
|-
|Nov 2, 2025
|2024.1.3
|-
|Jan 21, 2026
|2024.1.4
|-
|Mar 22, 2026
|2024.1.5
|-
|June 4, 2026
|2024.1.6
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release (except 2024.1, for whatever reason).

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="4" | [[BIKF]] || rowspan="4" | Keflavik
|-
| 2020.2
|-
| 2020.3
|-
| 2024.1
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [https://github.com/clolsonus/FlightGear-vault Historic FlightGear code since 1996] ([https://forum.flightgear.org/viewtopic.php?f=42&t=42351 forum])
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}
[[fr:FlightGear history]]

[[Category:FlightGear]]
[[Category:Articles to be updated for each release]]

Flight planning

2026-06-29T03:33:00Z

Celesta: add simbrief

'''Flight planning''' is the act of describing a flight to let controllers know you will be flying from an airport to another via a certain route and to calculate the fuel needed for your trip.

== Prerequisites: getting charts and checking the weather and NOTAMs ==
# The first thing you will need to do is to [[Getting aeronautical charts|get aeronautical charts]] for the departure and arrival airports.
# You should then check the weather at your departure and destination airports: this is done by [http://aviationweather.gov/adds/metars/ retrieving the latest METAR] for the airports. The METAR is a text string summarizing weather conditions of particular interest to pilots (like winds, visibility, cloud layers). Discussing in detail the structure of a METAR is beyond the scope of this page; you can refer to the [http://vateud.net/pilot-material/meteorology VATEUD training pages], or just use a [http://www.skystef.be/metar-decoder.htm METAR decoder].
# Then, [https://www.notams.faa.gov/dinsQueryWeb/ check the NOTAMs] (Notices to Airmen) for the origin and destination airports to get an updated list of potential hazards/procedural changes. Pay particular attention to closed runways/taxiways.

== Choosing a route ==
Aircrafts never fly straight (or "directly") from an airport to another, but follow predetermined flight paths known as ''airways''. (It's just like driving a car - you drive along existing known routes to get to your destination.) Airways intersect at ''waypoints'', and each of them is identified by a five letter code; thus, to determine your route, you just need to know the list of waypoints you will fly over.

# '''Choose a route to fly'''. To plan your route, we suggest to use a dedicated site such as [http://www.simroutes.com/fb2/ShowPlans.aspx SimRoutes] or [http://www.rocketroute.com/ RocketRoute].
# '''Choose a cruise altitude''', keeping in mind the following ''semicircular level rule'':
#* if the angle between the North and the line connecting the origin with the destination airport, measured clockwise, is between 0 and 179 degrees, you must fly at an odd thousand feet altitude (or "odd flight level");
#* otherwise, you must fly at an even thousand feet altitude (or "even flight level").
#: Some regions adopt different policies; for example, Italy, France, Switzerland, Spain and Portugal use odd flight levels for southbound flights, and vice versa.
# '''Look for airports along the route you chose'''. In case any problems arise with your aircraft during your flight or the weather conditions worsen, knowing where the nearest fields are and diverting there could avoid a crash. Normally, pilots design one or two airports as "alternates" (preferred aerodromes should they be unable to land at their destination).
# '''Calculate the amount of fuel required''' for the trip - that will vary according to:
#* the aircraft type;
#* the cruise altitude;
#* the load (more load requires more fuel);
#* the current winds (flying into the wind requires more fuel);
#* the congestion at the departure and arrival airports (more traffic means more taxi time and more time spent in a hold before landing, that is, more fuel consumption).
#: The best way to perform this calculation is to use a [http://www.fuelplanner.com/ fuel planner] or to use a flight planning site as described above; an alternative is to fly the route a couple of times, noting the fuel usage. Always keep in mind this rule: ''when in doubt, take more!''

== Filing a flight plan ==
[http://flightgear-atc.alwaysdata.net/ Lenny's website] is the tool currently used by:
* FlightGear ATCs to announce the times and dates they are going to offer ATC service;
* pilots to file (communicate to controllers) their flightplans.

Go to the site and check if a controller is manning your departure or arrival airport. If that's the case, ''file your flight plan'' (tell it to the controllers so that they'll be aware of your route and won't have to ask you about it). To do that:
# click on the aerodrome ICAO code to '''check the remarks''' left by each controller and take note of them. They will often state which voice communication method is used ([[FGCom]], Mumble or others);
# at the top of the page, in the ''My callsign'' box, '''put the callsign''' you will be using when flying;
# '''fill in the departure and arrival airports/dates and times''';
# if you want to give additional information, which is recommended, click on ''Additional info'' and fill in the fields that will appear; we suggest you enter at least your cruise altitude and route/waypoints. Use the ''Comments'' box to write any information that the ATC might find useful (e.g. if you are able to communicate on FGCom/Mumble or not);
# when you're satisfied, click on ''File this flightplan''.

== Related content ==
* [https://github.com/tdammers/fg-simbrief-addon SimBrief import] addon - Import flightplans, weights, fuel, and winds alof from SimBrief.

[[Category:Aviation]]
[[Category:Air Traffic Control]]

[[es:Planificación de vuelo]]