Skip to content

Flight dynamics

Orbit, access, atmosphere, and the library behind them

This page is the technical picture of how ASTROLAB treats motion, geometry, and environment. It is not a description of internal modules. For which buttons to press, use Assets, Analyses, and Scenario.

ASTROLAB’s flight-dynamics kernel is Orekit (see Orekit in ASTROLAB).

Orbit

A spacecraft state (position and velocity, or equivalent elements) is advanced over the mission interval. That trajectory feeds the 3D scene and almost every analysis (access, coverage, power incidence, lifetime, …).

  1. You set an initial state (Keplerian, Cartesian, …) at an epoch, or load an external ephemeris.
  2. You choose a propagator family.
  3. The study samples the trajectory on the scenario time grid (and any analysis-specific step).
  4. Design and analyses query position and attitude at those times.
flowchart LR
  IC["Initial state / ephemeris"] --> Prop["Propagator"]
  Forces["Force models"] --> Prop
  Scenario["Scenario start / end / step"] --> Prop
  Prop --> Ephem["Samples"]
  Ephem --> Scene["Design"]
  Ephem --> An["Analyses"]

Scenario time grid

Setting Role
Start / end UTC Bounds of the mission study
Step [s] Default sampling for the scene and many analyses
Plan floor Lower tiers cannot pick an arbitrarily fine step — Plans

Explore with a coarse step (for example 60 s). Tighten only when contact edges, coverage gaps, or reports need it.

Frames and state types

Concept In ASTROLAB
Inertial frames EME2000, GCRF, TEME, TOD, MOD, …
Earth-fixed ITRF under IERS Conventions 2010 (CIO / Earth Rotation Angle) — Orekit getITRF(IERS_2010, true). That is the current IERS conventions edition, not a realization named ITRF2010 (there is none). The latest ITRF realization is ITRF2020; ASTROLAB does not pin it. GMAT EarthFixed is the older FK5 / IAU 1980 chain — Independent verification.
State types Keplerian, Cartesian, Equinoctial, Delaunay

Keplerian / Equinoctial / Delaunay need an inertial frame (not ITRF). Orbit wizards (LEO, SSO, GEO, Molniya, …) are on the spacecraft Orbit tab — Spacecraft.

Propagator families

Family Typical use Notes
Keplerian Fast demos, first scene preview Two-body; no drag / SRP
Eckstein–Hechler Analytical LEO-style studies Analytical perturbation model
Semi-analytical (DSST) Long-horizon mean motion (lifetime, station keeping) Efficient over years; Lifetime locks to this family
Numerical Higher-fidelity short–medium arcs Integrator + selectable force models

Numerical force models (when that family is selected):

Option Effect
Gravity degree / order Spherical-harmonic Earth gravity
Atmospheric drag Density from the chosen atmosphere model × Cd × area / mass
Solar radiation pressure SRP with Cr and area
Third-body point masses Selectable bodies; default Sun and Moon when the list is omitted

Attitude is separate from orbit. Nadir, LVLH, sun-pointing, and similar laws orient boresights and panels; the propagator places the bus. Sensors and solar arrays depend on both.

Fix mass, Cd, and drag area before trusting Lifetime. After orbit edits: Apply Changes, then refresh the scene.

Numerical LEO versus GMAT, from gravity-only (0×0 / 30×0 / 30×30) through exponential drag, Sun/Moon, and spherical SRP: Independent verification.

Access

Access is the set of time intervals when a geometric (and constraint) relationship between assets is true. Link, Coverage, and Connection Network are all built on that idea. Routing and Latency then walk those windows; they do not invent extra geometry.

At a sample time the study:

  1. Places each participant (orbit, fixed facility, vehicle path, …).
  2. Tests line-of-sight / Earth occultation.
  3. Tests sensor FOV and pointing, or antenna boresight when that matters.
  4. Tests facility elevation and other geometric masks.
  5. Applies platform constraints (range, eclipse, illumination, beta, altitude, …).
  6. If every required test passes, the sample is in access; edges become intervals (high-accuracy coverage may refine edges).
flowchart TD
  Prop["Place assets at t"] --> Ray["LOS / horizon"]
  Ray --> Fov["FOV / pointing / elevation"]
  Fov --> Cons["Constraints"]
  Cons --> Hit{"Satisfied?"}
  Hit -->|yes| Open["Access"]
  Hit -->|no| Closed["No access"]
Analysis How it uses access
Link Pairwise intervals, optional RF budget on top
Coverage Many samples over a grid or demand set
Connection network Access on each declared edge
Routing / Latency Consume stored windows as a time-varying graph

Constraints gate participation; they do not replace geometry. Empty Link or Coverage is often min elevation too high, FOV off the AOI, eclipse / illumination rules, a range cap shorter than the slant range, or a time step that skips a short pass. Catalogue: Constraints.

Finer steps catch short contacts and cost more. Coverage Fast / Balanced / High Accuracy / Custom (temporal resolution, bisection, min access duration) are documented on Coverage — Computation. Svalbard contact edges versus GMAT (same engine): Independent verification.

Atmosphere and environment

“Atmosphere” appears in three places. Mixing them is a common reason Lifetime and Link budget numbers disagree.

Layer What it models Where you set it Who uses it
Neutral density (drag) Upper-atmosphere mass density Spacecraft numerical propagator / Lifetime / Station keeping Orbit decay, long-horizon Δv
Optical environment Clouds, visibility, aerosols (EO/IR climate) Scenario → Environment → Optical Optical context — not thermospheric drag
RF climatology Rain, gases, and cloud liquid on a slant path Scenario → Environment → RF Link budget L_atm, if that analysis includes atmospheric loss
flowchart TB
  Dens["Density models"] --> Drag["Drag ∝ ρ · Cd · A / m"]
  SW["Space weather / solar activity"] --> Dens
  Drag --> Life["Lifetime / numerical orbit"]
  RF["ITU / custom RF"] --> Link["Link budget"]
  Opt["Optical presets"] --> Scene["Optical context"]

Neutral density (drag)

Density varies with altitude, local time, latitude, season, and solar / geomagnetic activity (an expanded thermosphere means more LEO drag).

Model Engineering view
NRLMSISE-00 Widely used empirical thermosphere; common default
DTM2000 Empirical, drag-oriented
Harris–Priester Classic density vs altitude and local time
Simple exponential Orekit one-band ρ(h) at a 200 km reference (ρ₀ = 2.54×10⁻¹⁰ kg/m³, H = 50 km). Same band as the GMAT drag verification case — Independent verification

Space weather source (for example CSSI Space Weather or Marshall Solar Activity Forecast) and solar activity (Low / Moderate / High, or Compare All on Lifetime) are part of the assumption. Record model + activity when you publish a lifetime or LEO station-keeping number.

Spacecraft mass, Cd, and drag area are the other half of the drag acceleration.

Optical environment

Configured under Scenario → Environment → Optical: scene preset, cloud cover, horizontal visibility, AOD, optical transmission, diffuse skylight. They describe imaging climate. They do not replace sensor FOV, and they are not the density used for LEO drag.

RF climatology

Configured under Scenario → Environment → RF, and added in Link only when Include atmospheric loss is on. Maps are ITU-R P.837 (rain rate exceeded 0.01% of the year), P.839 (rain height), P.1510 (temperature), P.836 (water vapour), P.840 (cloud liquid), and P.1511 (topography). Rain specific attenuation uses the P.838-3 coefficients. The slant lengths are simplified: rain is γ_R times the geometric path up to the rain height, cloud is K_l L / sin θ, and gases are a short approximation times 6 / sin θ, not the full P.676 catalogue or the P.618 path-reduction factor. Monthly mode changes temperature only. This layer is not the density used for drag. Scenario · Link.

Choosing assumptions

Study Prefer
First LEO demo Keplerian, no drag
Lifetime / disposal Semi-analytical + a named density model + a documented solar case
Sensitivity Lifetime Compare All
RF margin in rain Link budget + RF climatology; leave the drag model alone
Optical tasking narrative Optical environment + Coverage / illumination constraints

Analyses (physics mapping)

Each analysis page in the catalogue is the user guide. Technically they share the ingredients above:

Analysis Relies on
Coverage Access over a grid, events, or static points
Link Pairwise access; optional RF budget and Scenario RF climate
Connection network / Routing / Latency Access windows on a declared mesh. Opt-in dump/command paths use Contact Graph Routing (CCSDS SABR / IETF CGR)
Power Orbit + attitude + eclipse for array incidence; batteries and loads
Lifetime Long-horizon drag (density + solar activity)
Station keeping Analytical Δv to stay in a LEO or GEO box under the same environment idea

Dashboard only plots finished results. Re-run a stale study after you change orbit, constraints, or environment.

Orekit

ASTROLAB uses Orekit, the open-source space flight dynamics library used across the industry for operational and study-grade orbit work. ASTROLAB does not re-validate Orekit’s integrator; Independent verification is a code-to-code check of our configuration and of the access engine against GMAT.

Item Value
Orekit 13.1
Project orekit.org
License Apache License 2.0 — Open source licenses

What that gives the product: time scales and frames, orbit representations and propagators, events used by access-like studies (eclipse, elevation, …), and force models (gravity, drag, SRP, third bodies).

You configure spacecraft and analyses in the UI. You do not call Orekit APIs as an end user. Patch builds may vary slightly; 13.1 is the supported major.minor baseline in this Beta.