Preface

In this post I continue a chain of previous posts, dedicated to questions of automatic control of simulated spacecraft we used in Operation “Silent Giant” simulated space mission.

Motivation

Fast-paced operations with intercept or rendezvous non-cooperating target in space require two-impulse transfers, developed by solving Lambert problem.

Such transfers suppose sophisticated and precise full three-dimensional maneuvering.

Control of spacecraft on such maneuvers is very difficult for a crew (it’s hard to provide enough precision of aiming and timing manually).

That’s why for our project we needed an autopilot.

Purpose

By initial idea, orbital autopilot for DeltaGlider had to be able to:

• Get maneuver parameters from operator through input
• Built spacecraft attitude required for maneuver
• Complete maneuver burn in the moment when it was required

Seems simple, right? Like, calculate everything in GMAT, enter values, and just wait while autopilot complete the maneuver. But, as always, “devil is in the details”. Practical tests showed that:

1. Actual spacecraft trajectory is always slightly different than modeled.
2. It’s very uncomfortable to transfer data (manually) from Orbiter 2016 to third-party mission design software and vise versa.
3. Because (1) and (2), getting into account that Lambert problem solver is very sensitive for input data, results of design of a transfer can be incorrect.
4. Perturbations caused by gravity gradients, pull of third bodies, atmospheric drag, etc. always disturb trajectory from planned, so it needs corrections.

So real implementation must been made with getting in count this details.

Actual functional

Final implementation of an orbital autopilot included:

1. Mission planning mechanism, based on “choices” concept (every maneuver treated as “choice”, building new “state” of a flight). The mechanism included:
   1. List of choices, with functions for manipulation of choices (addition, deletion etc.)
   2. Functions for designing choices (for single maneuver, two-impulse Lambert transfers, etc)
2. Trajectory modelling algorithms, based on Kepler propagaion algorithm and impulsive burns
3. Trajectory assessment functions, based on Tisserand-like criteria
4. ADCS functions, allows to determine and build proper attitude for applying maneuvers
5. Burn control functions, allows to perform precise burn
6. Visualization functions, plotting graphical representation of all required parameters on MFD screen.

Implementation

Summary

The solution looked pretty complex. To implement all its functional, I had to leave mfd/controller architecture I used in Atmospheric AP and Reentry AP.

Orbital AP C4 diagram

To make brief image of Orbital AP architecture, you can look at its C4 diagram, presented in file attached to this post.

In further explanations I will use it as a base for description.

Behavior logic

Because Orbital AP had to have multiple functions, deeply different by purpose, I decided to use modular structure, relying on combination of template method and decorator pattern.

Behaviours of autopilot (control of maneuver, manipulating list of “choices”, maneuver planning etc.) was separated into relatively independent components, which are able to load into template of UI, which in same time worked for them as a wrapper (decorator), passing to them system calls. Each of “behaviors”, same time, worked as decorator for different functions of Systems or controller containers.

Systems container

Systems container contained code implementing internal system functions, including specific recalculations for presentation of flight data in UI, logic of manipulation of list of choices elements, and control logic, used in controller.

Control logic was heavily fragmented into a primitives separated into multiple levels, like:

• Aiming control
• Thrust control
• Burn control (medium level control, controlling thrust)
• Orbit discrepancy control (assessment of current drift from modeled orbit)
• Orbital correction control (higher level control, uniting discrepancy control to see the drift, burn control to perform correction burn and aiming control for aim spacecraft for proper correction burn)

This deep fragmentation allowed to separate complex control problem into very simple and testable cases, which allowed me to make reliable and stable control.

Algorithm container

Algorithm container contained code of mathematics, astrodynamics and application algorithms. Mathematical algorithms included:

• extensions of standard LUA math functions (for example, equality with tolerance)
• implementations of linear algebra (vectors, matrix and quaternions calculations)
• numeric solutions (including split-half min/max search)

Astrodynamical algorithms included:

• Kepler propagator
• RV state <- -> Classic Orbital Elements convertor.
• Time Of Flight determination algorithm
• UTC -> Julian Date convertor
• Lambert problem solver (in universal variables, plus minimum energy solution for test purposes)
• Targeting algorithm (including surface collision detection and simple Hohmann transfer calculator for test purposes and checking minimums for solutions)
• Algorithms for assessing of orbit similarity (based on Tisserand criteria and used an idea offered by ChatGPT).

Most of mentioned algotihms was implemented following recommendations from from “Fundamentals of Astrodynamics and Applications”, Fourth Edition, by David Vallado.

Application algorithms included:

• set of coordinate systems conversion algorithms
  Orbiter 2016 uses left-handed (!!!) coordinate system, inherited from DirectX laying in the foundation of its engine, so all vector values gathered from simulated sensors of DeltaGlider had require simple but annoying transformation
• set of algorithms for ADCS systems
  Vector values from simulator was presented in a coordinate system which by sense was non-linked with coordinate system used in my trajectory modelling algorithms. Quaternion rotations gave wrong results. So I had to “represent” state vectors from simulator into my CS using Rodrigues transformation.
• set of “choice-making” algorithms, building “choices” (maneuvers) from different initial data
• delta-v map and maneuver optimization algorithms

For intercept/rendezvous maneuver optimization I used Two-Stage Zoom algorithm, using logic initially offered by ChatGPT. Principle of the algorithm explained in one of my previous posts and on next picture:

Nothing special, but with proper grid size it allowed drastically (about 100 times!) increase speed of optimization calculation, achieved calculation timings:

• for time-constrained Lambert transfer – 0.03 sec.
• for delta-v optimized Lambert transfer – 0.23 sec.

All algorithms in container were optimized for non-blocking execution in RTOS environment of MFD (utilizing LUA coroutine mechanism).

During development of Algorithm container I strictly followed TDD approach. Test coverage achieved ~98%.

mfd and controller

Base elements of all my autopilots for DeltaGlider also presented in Orbital AP, but their role is greatly reduced.

mfd serves as receiver of an input and system calls, and as a wrapper/template for behaviors. Its role reduced to UI drawing system, input receiver and executor of protected calls.

controller works mostly as a host cycle for execution of control algorithms from Systems container. In contrast with Atmospheric AP and Reentry AP it additionally uses prestep() call to form part of status returning to mfd.

Implementation notes

Overall “pure” time required for implement Orbital AP was about 2 month of work.

Important to note, that part of solutions for Orbital AP (including UI drawing functions, error processing and other “simulator-specific” code) was taken from Atmospheric AP and Reentry AP. Additionally, astrodynamics algorithms was taken from my astrodynamics library, so I did not need to implement and test in “from scratch”.

During the work, I widely used AI (CharGPT v.4) as co-programmer and support operator.

I already utilized AI support in my previous commercial projects, so usage of ChatGPT wasn’t something new in my practice. By my previous experience, I knew that usage of AI can 33% reduce total time costs of a project.

But here this did not work. As always, AI fails in topic-specific domains. It can not do your work for you. So, I can say that AI reduces total time costs of project (mostly because it can “type” the code for tests much faster than human). But in would not reduce the amount of your actual work.

Criticism

Practical realization of this orbital autopilot gave me invaluable experience.

Now, after successful end of the project, practical application of the system in simulator, and deep thoughts after this, I clearly understand that control software for orbital navigation must be implemented in different way.

So, in a nutshell, here is the main items of criticism:

• Orbital AP is over-complicated.
  This is a core critics for this app, and my typical mistake in cases when I don’t clearly understand the domain of operations. I am trying to prevent unknown consequences of vague decisions with a code. This causes wrong methods and approaches. Good orbital autopilot must be simpler.
  • Usage of simple propagation algorithms was a mistake.
    Simple Kepler propagator works good at altitudes from 1000 km to GSO and on short (less than 5 hours) arcs. Lower trajectory disturbed by atmosphere. On longer arcs trajectory curves under the pull of Moon and third bodies. Wrong modelling of trajectory causes errors in propagation prognosis, which causes a needs of often corrections, which in the end also fails. “Lower computation requirements” of Kepler propagator in this case got too high price (and in practice they are not so much lower than, for ex. RK4 with proper atmospheric model).
  • Active trajectory correcting was a mistake.
    Often corrections is also an evil. Don’t over-control it, just let it fly! Proper way – use precise modelling of trajectory and you will not face a case when your spacecraft “loosing” the trajectory. It looses it because you calculated it wrong! Typically, you need 1 correction per transfer arc, just to compensate small deviations, unavoidable during burns.
  • MFD interface needs improvements.
    Because of over-complicated logic of autopilot, UI is overloaded with functions. But problem will leave after simplification and improvement of core autopilot functions.