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, …).
- You set an initial state (Keplerian, Cartesian, …) at an epoch, or load an external ephemeris.
- You choose a propagator family.
- The study samples the trajectory on the scenario time grid (and any analysis-specific step).
- 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:
- Places each participant (orbit, fixed facility, vehicle path, …).
- Tests line-of-sight / Earth occultation.
- Tests sensor FOV and pointing, or antenna boresight when that matters.
- Tests facility elevation and other geometric masks.
- Applies platform constraints (range, eclipse, illumination, beta, altitude, …).
- 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.