Boris-Barboris / AtmosphereAutopilot

Plugin for Kerbal Space Program
GNU General Public License v3.0
48 stars 16 forks source link

AtmosphereAutopilot

Plugin for Kerbal Space Program.

Original author: Boris-Barboris.

Contributors:

License: GNU GPL version 3

Dependencies

ModuleManager.

For developers

How to build:

You need to build two dlls: AtmosphereAutopilot.UI.dll and AtmosphereAutopilot.dll. Both can be built from MS Visual studio on Windows using AtmosphereAutopilot.sln.
On Linux you need to run build.sh from root directory, wich requires the following packages:

General description

Atmosphere autopilot is a modular atmospheric flight control system library. It's meant to be a foundation for multiple high-level programs - "Autopilots", wich will aid KSP player in one way or another, implying atmospheric flight. Autopilots are mutually exclusive - only one or none at all may be active at the active vessel at one given moment. They are provided by the library with means of automatic reflection-based serialization\deserialization and ugly, but lazy and customizable GUI interaction.

Autopilots are modular entities. They can use basic, provided by main library components (like controllers and models), or they can define their own components and share them with other Autopilots. Those components will be called "Autopilot modules", or simply - "Modules". Every sealed child of AutopilotModule wich is not a StateController is treated by the library like a Module. Sealed StateController children are treated as Autopilots.

Stock and FAR aerodynamics are supported.

GUI concept

AA icon is placed in Application Launcher toolbar during flight. It's contents will visualize a list of all Autopilots and Modules, created for active vessel. For every vessel "Autopilot Module Manager" will be created regardless. Turning on a "MASTER SWITCH" on it's window will create required context of Autopilots and Modules for this vessel. Under the master switch all Autopilots will be listed, for the user to choose one of them as an active one. Hotkey for Master switch is letter P, autoPilot. Can be changed in Global_settings.cfg file, Autopilot_module_manager section.

Craft settings window contains shotrcuts to most used moderation and tuning parameters of the craft, as well as provides basic preset functionality. Presets are saved in "Global_settings.cfg"/settings_wnd/profiles section.

Each Autopilot and Module has it's own GUI window. All of them (even inactive ones) are accessible from AA button in Application Launcher, some of them are accessible from Autopilot window hierarchy (that's up to Autopilot developer to decide, what particular Modules should be accessible from it's GUI). Window positions are serialized (preserved between flights and game sessions) in "Global_settings.cfg" file.

Neo-GUI

Alternative, more condensed but less powerfull way of representing AppLauncher window can be turned on by setting AtmosphereAutopilot/use_neo_gui to true in Global_settings.txt config file. It is read every scene change, so the shift can be made without shutting KSP down. While it's active, "Autopilot Module Manager" is still accessible using hotkeys. Standard GUI has logical priority over Neo-GUI.

Hotkeys

"Hotkey manager" window is placed into Application Launcher window list. It's contents are registered hotkeys, wich can be changed during runtime. There are two main hotkeys:

Others are very module-specific and will not be described here.

Craft implications and limitations

"Control from here" part is facing prograde, with close-to-zero angle of attack bias. Planar symmetry is implied (left and right side of the plane are mirrored), as well as good degree of pitch-yaw and pitch-roll control isolation. Axial engine symmetry is strongly recommended. No wind mods are supported, as well as any mods, wich are changing control surface, rcs and engine gimbaling behaviour.

WARNING: DO NOT USE AEROBRAKES AS CONTROL SURFACES, USE THEM ONLY AS BRAKES!

Default Autopilots descriptions

Standard Fly-By-Wire

In general, FBW (Fly-By-Wire) is an abstraction Autopilot. It is designed to aid in player-controlled flight on generic (space)plane, providing a soft layer between user joystick\keyboard input and control surface outputs. Main goals:

FBW uses three controllers - pitch, roll and yaw. Pitch is handled by "Pitch ang vel controller", roll by "Roll ang vel controller" and yaw is handled by "Sideslip controller" in plane mode, or directly by "Yaw ang vel controller" in "Rocket mode". In Rocket mode pitch and yaw axes are treated the same - it's usefull in case player wants to use FBW for rocket launches. FBW is effective only on small (<25 degrees) AoA values, though control is possible on all regimes. It's just that it's quality will degrade from inadequacy of linearization assumptions. "Moderation" button is toggling all pitch and yaw moderations - usefull for low speed VTOL action or for fighting overmoderation bugs. Pitch moderation is turned off for 2 seconds after taking-off to prevent overmoderation-related crashes.

"Coordinated turn" - pseudo-pitch hold to assist in performing coordinated turns.

Hotkeys:

Speed control - throttle automation to maintain speed setpoint. Handeled by "Prograde thrust controller".

Mouse Director

Mouse Director (MD) is declarative autopilot, crafted with idea to let the user to define desired airspeed direction with camera position. Autopilot then tries to comply with this surface-relative velocity setpoint. MD is inherently-linear, so only relatively small angles of attack are allowed. All AoA moderations are forcefully turned on during it's operation.

MD uses "Director controller", wich uses two AoA controllers: pitch "AoA controller" and yaw "Sideslip controller", and "Roll ang vel controller" for roll. Currently, planar asymmetry of a plane is not taken into account (sideslip noise is still too noticeable in zero-lift convergence problem), sideslip is always at zero setpoint. If your craft requires nonzero sideslip to fly straight, MD is not a very good solution right now, use FbW in the rocket mode.

Short GUI description:

Speed control - throttle automation to maintain speed setpoint. Handeled by "Prograde thrust controller".

Cruise Flight controller

Cruise Flight (CF) is high-level autopilot, designet for travel automation. Just like MD, CF is inherently-linear, so only relatively small angles of attack are allowed. All AoA moderations are forcefully turned on during it's operation.

CF uses "Director controller" for controlling velocity vector and "Prograde thrust controller" for throttle automation. Functions:

Short GUI description:

"Advanced options" description:

Hotkeys:

AoA-hold

AoA-hold (AoAH) maintains pitch Angle-of-Attack setpoint. Pitch AoA moderation is forcefully turned on during it's operation.

AoAH is very similar to Standard Fly-By-Wire. It uses "AoA controller" for pitch, roll is handled by "Roll ang vel controller" and yaw is handled by "Sideslip controller".

Short GUI description:

Hotkeys:

Default Modules descriptions

Flight Model

It is a fundamental craft analysis module. It performs motion and dynamics evaluation, as well as analysis of craft aerodynamics. VTOL engine balancing is also handled by Flight Model (though it will probably change in the future). This Module will probably be used by every single other Autopilot and module.

Short GUI description (consult source code for more deatils and insight):

Hotkeys:

Director controller

Middle-level model-reference controller, follows a setpoint of surface velocity and acceleration vectors. Input: velocity vector and acceleration vector. Output: AoA, sideslip and roll angular velocity.

Short GUI description:

Pitch, roll and yaw angular acceleration controllers

Low level dynamics inversion angular acceleration controllers. Input: desired angular acceleration (and yaw output for roll controller). Output: pitch\roll\yaw control state.

Short GUI description:

Pitch and yaw angular velocity controllers

Model-reference controllers, that perform pitch and yaw angular velocity control with respect to moderation and controllability restrictions. Input: [-1, 1] user input or desired angular velocity. Output: desired angular acceleration, passed to angular acceleration controller.

When navball is in surface mode, controller is dealing with surface-oriented reference frame. Zero input will keep zero angular velocity relative to the ground - useful on planes. In orbit navball mode inertial reference frame will be used - usefull for spacecrafts. Precision mode (CAPS LOCK) multiplies input by the factor of 0.33 (precision mode factor option in global_settings.txt) to provide more precise control, or to aid with control on high physical warp regimes. To ignore precision mode, unser watch precision mode toggle in respected ang vel controllers.

Short GUI description:

Roll angular velocity controllers

Model-reference controller, that perform roll angular velocity control and wing leveling. Input: [-1, 1] user input or desired angular velocity. Output: desired angular acceleration, passed to angular acceleration controller.

Precision mode (CAPS LOCK) divides input by the factor of 3 to provide more precise control, or to aid with control on high physical warp regimes.

Short GUI description (except identical from previous module):

AoA and Sideslip controllers

Model-reference controllers with self-explanatory names. Input: [-1, 1] user input or desired AoA. Output: desired angular velocity. Both require respective angular velocity controllers to have AoA moderation on, because it uses respective angular velocity controller limitation values as governers.

Short GUI description:

Prograde thrust controller

Hybrid model-reference or PID controller. Input: desired surface velocity. Output: throttle. Can be switched to PID control and manually tuned, if user is not satisfied with it's performance.

Short GUI description:

Hotkeys: