{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Orbital Congestion\n",
"---\n",
"**Milestone 1 Project - SIADS 591 & 592**\n",
"
February 3, 2021\n",
"\n",
"*Project Team:*
\n",
"Tim Chen (ttcchen@umich.edu), Sophie Deng (sophdeng@umich.edu), and Nicholas Miller (nmill@umich.edu)\n",
"\n",
"*Instructional Team:*
\n",
"Elle O'Brien (elleobri@umich.edu), Chris Teplovs (cteplovs@umich.edu), and Anthony Whyte (arwhyte@umich.edu)\n",
"\n",
"*GitHub Repository:*
\n",
"https://github.com/mads-hatters/SIADS-591-Orbital-Congestion\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 1. Table of Contents\n",
"\n",
"\n",
"\n",
"1. [Table of Contents](#table-of-contents)\n",
"2. [Motivation](#motivation)\n",
"3. [Brief Introduction to Orbital Mechanic](#intro)\n",
"4. [Data Sources](#data-sources)\n",
" 1. [Space-Track.org](#ds-spacetrack)\n",
" 2. [SCORATES](#ds-socrates)\n",
" 3. [NASA (History of On-Orbit Satellite Fragmentations)](#ds-fragments)\n",
"5. [Data Manipulation Methods](#data-manipulation)\n",
" 1. [SOCRATES Web Scrapper](#dm-socrates)\n",
" 2. [Satellite Break-Up PDF](#dm-breakup-pdf)\n",
" 3. [Satellite CZML Generator for Cesium](#dm-cesium)\n",
" 4. [Downloading Satellite General Perturbations Data](#dm-spacetrack)\n",
" 5. [Detection of Orbital Maneuvers](#dm-maneuver)\n",
" 6. [Looking for Risk Mitigation Maneuvers](#dm-evasive)\n",
" 7. [Gabbard Animation for Debris](#dm-agabbard)\n",
"6. [Analysis and Visualization](#analysis-visualization)\n",
" 1. [Satellite Congestion History](#av-history)\n",
" 2. [Visualize in 3D](#av-3dvisual)\n",
" 3. [Orbital Maneuver Detection](#av-maneuvers)\n",
" 4. [Collisions and Near Misses](#av-collisions)\n",
" 5. [Debris Gabbard Diagram Animation](#av-agabbard)\n",
" 6. [Starlink and Future Super Satellite Clusters](#av-starlink)\n",
"7. [Conclusion](#conclusion)\n",
"8. [Statement of Work](#sow)\n",
"9. [Glossary](#glossary)\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 2. Motivation\n",
"\n",
"Space, and more specifically low-earth orbit, is about to get a whole lot busier and this is making many concerned. At present, there are about 2,000 operational satellites in low-earth orbit and more than double that in defunct satellites. But last year in October, SpaceX requested permission to launch 30,000 Starlink satellites into low-earth orbit. This is in addition to the 12,000 that already received approval. These satellites have already begun interrupting astronomical observations, creating light pollution and increasing collision risks in an environment where a collision could trigger a chain reaction which not only endangers current and future satellites but also human lives. \n",
"\n",
"For our project, we will be looking into the present situation with satellite counts, ownership, purpose, and their corresponding orbits. We will use visualization techniques such as spatial density charts, gabbard diagrams, and animated time series charts to illustrate orbital congestion and highlight intersecting orbits that have the potential for collision. In addition to satellite data, we will explore debris in space. Using this data, we intend to investigate several questions and present an analysis that can be used for future work."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"[Back to Top](#table-of-contents)\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 3. Brief Introduction to Orbital Mechanic\n",
"\n",
"The following are a few terms that will be used in this document. For a comprehensive list, please check the [glossary](#glossary).\n",
"\n",
"\n",
""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"[Back to Top](#table-of-contents)\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 4. Data Sources"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### A. Space-Track.org\n",
"| Data Source 1 | Space-Track.org |\n",
"|:--|:--|\n",
"| *Name* | Satellite Catalog and ELSET data provided by the Combined
Force Space Component Command's 18th Space Control Squadron |\n",
"| *Size of Data* | Almost 50,000 cataloged objects in space, their metadata,
and multiple daily historical ELSET data. |\n",
"| *Location* | https://www.space-track.org/documentation#api |\n",
"| *Format* | CSV
Two-Line Element (TLE)
Orbit Mean-Elements Message (OMM) |\n",
"| *Access Method* | Direct download, API Access, or open source Libraries
More details below. |\n",
"\n",
"Space-Track.org contains a number of vaste historic and up-to-date datasets for satellite tracking that can be accessed via an API. The following Request Classes were used for this project:\n",
"\n",
"| Request Class | Description |\n",
"|:--|:--|\n",
"| `gp` | The general perturbations (GP) class is an efficient listing of the newest
SGP4 keplerian element set for each man-made earth-orbiting object tracked by the
18th Space Control Squadron |\n",
"| `gp_history` | Listing of ALL historical SGP4 keplerian element sets for each man-made
earth-orbiting object by the 18th Space Control Squadron. |\n",
"| `satcat_debut` | Satellite Catalog Information with satellite catalog debut time |\n",
"| | *Further information can be found here:*
https://www.space-track.org/documentation#/api |\n",
"\n",
"To access Space-Track.org data, login credentials are required. Free accounts are available here: https://www.space-track.org/auth/createAccount. With an account, the API can be accessed via an online query builder or via a python package such as spacetrack. Both of these methods were used for this project."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### B. SCORATES (Satellite Orbital Conjunction Reports Assessing Threatening Encounters in Space)\n",
"| Data Source 2 | Satellite Conjunctions Predictions (SOCRATES) |\n",
"|:--|:--|\n",
"| *Name* | Satellite Orbital Conjunction Reports Assessing Threatening
Encounters in Space |\n",
"| *Size of Data* | Up to 1,000 entries of predicted satellite or debris conjunction entries
for the next 7 days. |\n",
"| *Location* | https://celestrak.com/SOCRATES/ |\n",
"| *Format* | HTML |\n",
"| *Access Method* | Web scraping to CSV files |\n",
"\n",
"SOCRATES calculates the likelihood two satellites will collide based on recent satellite location and orbit via TLE data. The website displays upto 1000 satellite pairs based on either maximum probability of collision, minimum distance between satellites or sorted time of closest approach."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### C. NASA (History of On-Orbit Satellite Fragmentations)\n",
"| Data Source 3 | NTRS - NASA Technical Reports Server |\n",
"|:--|:--|\n",
"| *Name* | History of On-Orbit Satellite Fragmentations, 15th Edition |\n",
"| *Size of Data* | a document of size 3954 KB |\n",
"| *Location* | https://ntrs.nasa.gov/ |\n",
"| *Format* | PDF |\n",
"| *Access Method* | Download from the server |\n",
"\n",
"NASA provides a history of satellite break-ups which is useful in determining when debris from break-ups originated since Space-Track.org data only has the date the debris is first tracked."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"[Back to Top](#table-of-contents)\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 5. Data Manipulation Methods"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### A. SOCRATES Web Scrapper\n",
"#### SOCRATES Scrapper\n",
"SOCRATES is a web service provided to the satellite community by the Center for Space Standards & Innovation (CSSI) which provides information on pending intercepts of satellites within a week. This information is valuable for predicting if and when two satellites collide based on probability and estimated minimal distance.\n",
"To capture this information, a web scrapper called socrates_scrapper_nm.py
was developed using the `BeautifulSoup` python package. The web data is tabularized and contains a single conjunction event across two rows which made using pandas built-in scrapper less reliable:\n",
"\n",
"\n",
"\n",
"\n",
"Twice a day, the information is updated and produces a massive amount of data, therefore, SOCRATES provides three different methods for retrieval [Maximum Probability, Minimum Range, Start Time]. And the maximum number of rows retrieved for each is 1000 events. Because of this, the web scrapper loops three times capturing the maximum amount of data.\n",
"The scrapper was written to run as a background job with output messages sent to a log file. Each execution of the scrapping job dumps the results into a new dataframe which is then saved in `./data/socrates/socrates_YYYYMMDDHHMISS.csv.gz`. The resulting structure:\n",
"\n",
"\n",
"\n",
"#### Getting TLE data\n",
"\n",
"One of the goals was to visualize the close encounters reported by SOCRATES in an effective way. To accomplish this, the TLE for each satellite is necessary. Getting the latest TLE for a satellite results in a large margin of error which is one of the reasons why TLEs are frequently updated. Space-Track.org has a retrieval class called `gp_history` for historical TLE records that was used for this data collection.\n",
"\n",
"One of the challenges in accessing the historic TLE data is that the API used to retrieve `gp_history` data is limited to 300 requests per hour. While exceeding it is possible and was done initially, Space-Track.org sends an email warning that repeated violations result in a permanent ban. Since each SOCRATES grab resulted in 3000 satellite pairs twice a day, creativity was necessary to grab the data in larger chunks and thus limiting the number of requests. This was accomplished by looking at all the SOCRATES data and comparing that to the TLE data previously retrieved and getting a list of missing (new) satellite pairs. Each satellite then needed an epoch date—the date of when a TLE was captured—to know which TLE should be retrieved from `gp_history`. SOCRATES didn’t contain this date but instead contained a “Days Since Epoch” value allowing for the backdate calculation. This unfortunately had an error of about five minutes but TLEs are at most captured every 30 minutes and usually are hours or days apart for one satellite.\n",
"\n",
"To address the soft cap of 300 requests an hour, the missing data was sorted by epoch date and grouped in batches of approximately 100 and assigned a bin number. Each bin would represent a single request. The request was then built passing a list of satellite NORAD ID numbers that existed in the batch and a start/end epoch window. This could result in the API returning multiple TLEs for the same satellite so the results needed to compare the epoch on the TLE to the approximate epoch calculated previously. The captured TLEs were saved off to a CSV as a safe guard if the merging process should fail so another API grab wouldn’t be necessary (this redundancy was never needed). The merging process consolidated each satellite pair with their TCA (time of closest approach) and appended the data to the TLE grab dataframe which would later be joined on demand with the SOCRATES data.\n",
"\n",
"The code for this TLE grab and merging takes place in a script called socrates_gp_history_tle_grab_nm.py
. This script was executed after each run of the web scrapper via a background job on a personal computer left on for about two months.\n",
"\n",
"\n",
"\n",
"Above is an example manual run. The first stage is the web scrapper which sends the output to a log file `log.log`. The second stage is the TLE grab shows the grab of 4502 missing TLE entries grouped into 46 API requests and then after merged with the SOCRATES TCA for each pair.\n",
"\n",
"#### SOCRATES Python Package\n",
"\n",
"Since the raw SOCRATES data contains many duplicates, there might be cases where the raw data might be analyzed and other cases where only the unique records joined with TLE entries would be necessary. To resolve this challenge, a new python package socrates
was created with several different options for loading the SOCRATES data. Those functions include:\n",
"\n",
"- `get_all_socrates_data()` - This loads only the raw SOCRATES data from all available files and merging them together without any cleaning of duplicate records.\n",
"- `get_socrates_cleaned_data()` - This calls `get_all_socrates_data(path)` and drops duplicates, keeping only the most recent.\n",
"- `get_socrates_with_tle_data()` - This merges the SOCRATES dataset (e.g. from `get_socrates_cleaned_data()`) with the TLE data grabbed for SOCRATES.\n",
"- `get_all_socrates_and_tle_data()` - This calls `get_socrates_cleaned_data()` and `get_socrates_with_tle_data()` and returns two datasets: the cleaned SOCRATES data and the merged data."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### B. Satellite Break-Up PDF\n",
"One issue with the data from Space-Track.org is the origin date of debris resulting from the breakup of satellites is the date the debris is first tracked and not the date of the satellite breakup. Tracking the date of breakup events is crucial to analyze the number of debris available over time as it provides accurate information on when debris were created and subsequently decayed. This information can be found in the form of tables from a PDF report called \"History of On-Orbit Satellite Fragmentations\" from NASA. \n",
"\n",
"To extract table information from the PDF, a library named Tabula was used:\n",
"- Install and set up Tabula (windows): Pip install tabula-py and java. If there’s a `FileNotFoundError` when it calls read_pdf(), set PATH environment variable to point to the Java directory.\n",
"\n",
"- The challenge of using Tabula comes from not reading the tables in PDF file according to the original page breaks. Tabula breaks 8 tables in 8 different pages into 20 dataframes which need to be manually cleaned and combined. In other words, if the satellite name spans multiple rows, Tabula splits it incorrectly into two rows, resulting in a second row with NaNs. Manual cleaning also involves update date format not recognized (i.e. 3/4Aug-15, ~21-Dec-11), removing footnotes and unnamed columns. "
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### C. Satellite CZML Generator for Cesium\n",
"\n",
"CesiumJS is an open-source GPL library that looks similar to the popular Google Earth platform. It is highly customizable and allows for painting of custom shapes and images onto and around a 3D model of the Earth built from satellite imagery. Since the imagery is licensed, a free API key is necessary to create the visuals.\n",
"\n",
"Getting Cesium to display properly on the Plotly Dash dashboard turned out to be challenging due to how Dash creates the different objects and calls javascript methods. After asking on Plotly Dash community pages and stackeoverflow, help was received on how to get around this problem.\n",
"\n",
"The Cesium platform also supports a file format called CZML, used to create time-based animations. To take advantage of this, the python package tle2czml
, developed by Shane Carty, was initially used to animate the intercepts of two satellites on the dashboard. However, this package is quite limited in functionality. For example, the coloring, markers, and marker descriptions are all static. An improvement to allow custom descriptions was made and a pull request was initialized but the developer hasn’t responded at the time of this writing. Because of these limitations, a custom python library called `satellite_czml` was created, which is now available as a python package available on PyPI.org and is open source on GitHub. The packge can be installed by calling the following:\n",
"\n",
" pip install satellite-czml\n",
" \n",
"This python package, like `tle2czml`, relies on a custom version of another python package called czml
, developed by Christian Ledermann and the python package sgp4
, developed by Brandon Rhodes (coincidently, the same developer of `skyfield`, discussed below). `satellite_czml` is now used in the dashboard to create the intercept and Starlink animations."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### D. Downloading Satellite General Perturbations Data\n",
"\n",
"#### Initial Manual Download Process\n",
"Space-Track provides a `gp_history` API for accessing all historical satellite TLE data. For the initial exploration and static charts, individual CSV files from the `gp_history` request class (request classes documentation) generated by the query builder was manually downloaded. However, this process was tedious and did not scale when comparing multiple satellites across different time periods, which is necessary for maneuver detection. Also considering other analysis which rely on `gp_history`, an automated processes to acquire bulk data became a necessity.\n",
"\n",
"#### Setting Up Automatic Downloads\n",
"Some challenges that had to be resolved for bulk downloads\n",
"\n",
"| Challenge | Description and resolution |\n",
"|:--|:--|\n",
"| *API limitations* | The API has a hard limit of 100,000 entries per request and a rate limit of 30/minute and 300/hour. With the `gp_history` data sitting at nearly 150 million entries, under optimal situations, 1,500 API calls over a period of 5 hours at the minimum. |\n",
"| *API authentication* | The API requires authentication using individual username and password. Credentials template files needed to be shared while individual crential files needed to be excluded from source control. |\n",
"| *Authorization duration* | The API only offers access tokens with 2 hour lifetime, with the large amount of long running jobs, resuability and automaticated re-authenticate was necessary. |\n",
"| *Platform support* | An ideal long term solution should be cross-platform as the team's development machines consisted of Windows and Mac. A method to have a jupyter notebook automatically run code was developed to avoid platform specific schedulers or a separate backend (see skeleton_autorun_below.ipynb
for proof of concept and skeleton code). |\n",
"| *Keeping data up to date* | The process must allow incremental updates when new data becomes available while ensuring that no entries are missed. |\n",
"\n",
"Initially, the script only downloaded satellite data with various LEO configurations in chronological order, however, sometimes data entries will be missing or spike when specific parameters cross certain thresholds (e.g. the LEO requirements). Ultimately, the script was modified to download practically all of the data with local filtering being performed based on specific data needs at a later time. The current numbers as of Jan 26th, 2021: 144,800,000+ `gp_history` entries stored in 1,449 files, taking up 80GB storage. These raw files are then compressed and stored without further processing as different analysis may require different columns.\n",
"\n",
"The code for this download process can be found at download_all_gp_history.ipynb
."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### E. Detection of Orbital Maneuvers\n",
"\n",
"Maneuver detection is possible by looking at abnormal readings in the TLE data. Initial exploration was done visually using data segments downloaded manually from Space-Track. Maneuvers are generally easy to spot visually, however, with the large amount of data, manual inspection for maneuvers could not scale. Automatic maneuver detection was needed. This section will provide an overview of how the data is pre-processed. Maneuver detection methods will be discussed in the analysis section.\n",
"\n",
"#### Challenges Encountered for Automatic Orbital Maneuver Detection \n",
"\n",
"| Challenge | Description |\n",
"|:--|:--|\n",
"| *Data Frequency* | Interval between TLE entries varies a lot - from 1 entry in 3 months to less than 2 hours between 2 TLEs. Some normalization is needed when using `.diff()` to examine the data. |\n",
"| *Data Accuracy* | Some data contains obvious errors which may be due to sensor errors or attributing TLE data to the wrong entity. There are also some duplicates in data that affects rolling windows using `.rolling()` and using `.diff()` to look at changes in data. |\n",
"| *Memory Requirements* | Due to the size of the data, loading in all the data has a really high memory demand.\n",
"\n",
"#### Reducing Orbital Elements Used\n",
"\n",
"When examining ISS's orbit data, some of the orbital elements appear to have direct correlation (such as `MEAN_MOTION`, `SEMIMAJOR_AXIS`, `PERIOD`, `APOAPSIS`, and `PERIAPSIS`, as well as `BSTAR` and `MEAN_MOTION_DOT`) while others are less suitable due to their periodic variance and noise (such as `ECCENTRICITY`, `ARG_OF_PERICENTER`, and `MEAN_ANOMALY`).\n",
"\n",
"\n",
"
filter_raw_data_payload_maneuvers_report_data.ipynb
):\n",
"\n",
"| Processing Stage | Number of Entries | Number of Columns | Column `dtypes` | DataFrame Memory Usage |\n",
"|:--|:--|:--|:--|:--|\n",
"| Raw CSV Input | 100,000 | 40 | `float64`(14)filter_raw_data_payload_maneuvers.ipynb
."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### F. Looking for Risk Mitigation Maneuvers\n",
"\n",
"With the increasing amount of satellites in Low Earth Orbit, an increased frequency of risk mitigation maneuvers is expected. To verify this hypothesis, data from the CelesTrak's SOCRATES dataset was again used. SOCRATES uses the same TLE data available from Space-Track to calculate potential satellite conjunctions for a 7 day period. With the SOCRATES data, pairs of satellites on a collision course (can be visualized in the dashboard) were identified, however, the information is limited to a specific time. In order to detect maneuver, a series of TLE data surrounding the conjunction time is required. Grouping of the predictions made was also needed to determine how the collision probability has changed during that 7 day period for each incident.\n",
"\n",
"#### Combining and Grouping SOCRATES Entries\n",
"To get the SOCRATES history of a particular possible collision, all the SOCRATES reports where combined into one DataFrame then grouped together based on the satellite pairing and the Time of Closest Approach (`tca_time`). Additional data manipulation was needed to set the proper group for `tca_time` due to pairs of satellites having multiple conjunction events. To filter down the selection further, entries which only contain objects that are known to have no maneuvering abilities, such as debris or spent rocket bodies, were removed. Non-LEO objects were also elimited as they were out of scope of the project. Finally, events with a predicted `max_prob` of 0.5% or greater were selected to do further investigations.\n",
"\n",
"With the maneuver dataset process already completed in [the previous section](#dm-maneuver), applying the appropriate `NORAD_CAT_ID` and `EPOCH` time range filter was the only necessary step to obtain the satellite data. A time range of 14 days prior to the first time a conjunction event was predicted to 5 days after the `tca_time` was chosen to provide the maneuver detection algorithm plenty of data to find maneuvers and to provide context during visual inspection of the individual events.\n",
"\n",
"The satellite catalog (SATCAT) was also merged to provide names of the satellites since some of that information was removed from an earlier reduction process.\n",
"\n",
"The code for this pre-processing can be found at detect_maneuver_from_socrates_suggestions.ipynb
."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### G. Gabbard Animation for Debris\n",
"\n",
"A Gabbard diagram shows the `PERIOD` of objects on the x-axis and their `APOAPSIS` and `PERIAPSIS` on the y-axis. An animated version of the Gabbard diagram would need these data over a period of time.\n",
"\n",
"#### Grouping Data for each Animation Frame\n",
"\n",
"Proof of concept for the animation was done using a small timeframe by grouping entries using the `dt.week`. This was not an ideal solution though, because week numbers do not reset with a year change, resulting in a flashback frame every year, and none of the aggregate features represented the satelite's position well due to how wide the time window was.\n",
"\n",
"Since a datetime `groupby` cannot be used, `reindex` and `interpolate` were used instead to have a more accurate representation of the data. A proof of concept was done by first performing a `unstack` so each satellite has its own column, then performing a reindex over the entire time period and interpolate missing data in between. However, this failed to scale spectacularly as the DataFrame size is now `m` * `n` where `m` is the number of objects * 3 (one for each of `PERIOD`, `APOAPSIS`, and `PERIAPSIS`) and `n` is the number of frames - exceeding billions of cells.\n",
"\n",
"An alternate strategy was developed, where each satellite would only generate its own valid time range in order to avoid the `NaN` cells prior to the it being tracked or after it decayed. This was achieved by performing the split-apply-combine process, grouping by `NORAD_CAT_ID` then applying the datetime index transformation along with the interpolation. Due to some errors in the data in the late 1970s, where incorrect TLEs were being attributed to satellites, it was also necessary to remove some outliers and to not interpolate impossible cases.\n",
"\n",
"#### Applying `dtype` Conversion\n",
"\n",
"To reduce memory usage, `dtype` conversion similar to the earlier maneuver detection process was applied. However, there is a difference in that the data for Gabbard diagrams allow for some precision loss since it can hardly be noticed due to the limited size of the charting area. This allows additional optimization when looking for a suitable `dtype` to use. The `dtype` conversion will be applied prior to grouping and interpolation. Every little *bit* (Ba Dum Tss!) counts with the with 86,326,993 rows of data!\n",
"\n",
"| Column | Import `dtype` | Notes | Final `dtype` conversion |\n",
"|:--|:--|:--|:--|\n",
"| EPOCH | `object` | Since further time-based grouping will be done at a later step, the `datetime64` precision was preserved for sanity purpose. | `datetime64` |\n",
"| NORAD_CAT_ID | `int64` | Similar to the earlier conversions, the `NORAD_CAT_ID` can be represented as an unsigned 16-bit integer for the near term. | `uint16`\n",
"| APOAPSIS | `float64` | For the purpose of generating LEO Gabbard diagrams, an `APOAPSIS` of > 3000 is out of range, thus, `APOAPSIS` can be represented by a `uint16` after a 20x scale resulting in a max precision of 1/20 step | `uint16` filter_raw_data_gabbard.ipynb
and the reindex and interpolation code can be found at: process_gabbard_data_interpolated.ipynb
.\n",
"\n",
"#### Annotating and Highlighting Events\n",
"\n",
"To annotate events in the animated gabbard diagram, data from the [Satellite Breakup PDF section](#dm-breakup-pdf) was used. Initially, all the data was filtered automatically based on time and orbit, however, manual selection was needed due to the clutter of many minor events during certain years, as well as some data being nearly invisible in the diagram. In the end, 79 events were chosen for their prominence and magnitude. One event was added (2019 Microsat-R anti-satellite test) as it happened after the publish date of the document, and another required manual attribution for debris pieces due to that particular launch being related to two multiple events (all other breakup events came from different launches).\n",
"\n",
"The code for generating the gabbard diagram animation can be found at animated_gabbard.ipynb
and the manually updated and annotated breakup file is stored as breakup_custom.csv
."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"[Back to Top](#table-of-contents)\n",
"\n",
"---"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"## 6. Analysis and Visualization\n",
"\n",
"A dashboard was created to summarize and present, in an accessible way, some of the interactive visuals discussed in this report. The dashboard can be accessed either online via Heroku or by running the notebook oc_dash.ipynb
in the source. Both options use the same source code and data sources.\n",
"\n",
"\n",
"skyfield
was used which offers the `EarthSatellite()` convenience function and outputs an x,y,z coordinate in kilometers with the center of the earth as the origin.\n",
"\n",
"\n",
"images/maneuver_analysis
.\n",
"\n",
"In the above chart, the left set of images represents detection methods for inclination adjustment maneuvers, while the right column represents detection for orbital raising / lowering maneuvers. These detection methods are ordered by sensitivy, with the `diff` type detection being highly sensitive while a large `rolling` window being less sensitive. Multiple thresholds were also selected for each method. The resulting graphs highlight time ranges in orange where maneuvers were detected. The lighter orange shades are detected by the most sensitive thresholds and while the darker orange shades only show more obvious maneuvers.\n",
"\n",
"Based on the results, `rolling_10_neighbor_diff`, comparing two rolling windows with size of before and after a point, with a threshold of 0.008 was selected for detecting inclination adjustment maneuvers, and a `rolling_3_neighbor_diff` with a threshold of 0.025 was selected for detecting orbit raising / lowering maneuvers. The results:\n",
"\n",
"| maneuvers_detection_method.ipynb
.\n",
"\n",
"While this could definitely be improved by taking into account other factors such as specific operational parameters (like Starlink's), solar activity, inclination variance, and orbital decay based on altitude, with this combination of detection methods and thresholds, the majority of the maneuvers has been identified and should be sufficient for identifying RMMs."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"\n",
"### D. Collisions and Near Misses\n",
"\n",
"\n",
"#### Collisions\n",
"Collisions between objects in space are hypervelocity collisions where the velocity (v) of the impactor (relative to the target) is so great that its kinetic energy ( $K = \\frac{m v^2}{2}$) is greater than the energy released in the detonation of the same mass (m) of high explosive. (Australian Space Academy, ret. 2020)\n",
"\n",
"In low Earth orbit, the velocity of a satellite is between 7 and 8 km/sec and the typical collision velocity between two space objects in LEO is around 10 km/sec. An accidental LEO collision will most likely be a hypervelocity collision. The deliberate destruction of a satellite with a launched missile is also a hypervelocity collision. A hypervelocity collision may be categorised as catastrophic or non-catastrophic. A catastrophic impact results in both the target and the impactor being totally destroyed while in a non-catastrophic event, the impactor is detroyed and the target is damaged.\n",
"\n",
"Fragments ejected from a collision will have a new orbit dependent upon the magnitude of the ejection velocity and the direction of this velocity vector with respect to the velocity vector of the satellite at the time of collision. If the velocity is in the same direction as the original target motion (A), the initial orbit will be turned into a larger elliptial orbit. On the other hand, if the velocity is in the opposite direction (B), the final orbit will become smaller than the initial orbit. This is illustrated in the figure below:\n",
"\n",
"\n",
"\n",
"\n",
"#### Gabbard Diagram\n",
"John Gabbard developed a diagram for illustrating the orbital changes and the orbital decay of debris fragments. A Gabbard diagram is a scatter plot of orbit altitude versus orbital period. Since all orbits are elliptical, a Gabbard diagram plots two points for each satellite: the apogee and perigee. Each pair of points will share the same orbital period and thus will be vertically aligned.\n",
"\n",
"\n",
"#### FengYun-1C Anti-satellite Missile Test\n",
"On 11 January 2007, a non-operational Chinese weather satellite, the Fengyun-1C (FY-1C) was destroyed by a kinetic kill vehicle (missle) traveling with a speed of 8 km/s in the opposite direction at an altitude of 863 km.\n",
"\n",
"The below Gabbard diagram illustrates the aftermath of this collision: \n",
"1) 3526 pieces of debris of trackable sizes are documented and 646 pieces have decayed.\n",
"\n",
"2) The cross sign (x) marks the location of collision at the altitude of 863km which is low earth orbit(LEO). When a collision happens at a low altitude, some of the fragments ejected in the opposite direction to the original motion will be forced into orbits with a perigee below the Earth's surface. As a result, these fragments with smaller mass will generally burn up during reentry. Those of a larger mass tend to decay later due to their momentum until atmospheric drag causes them to deorbit.\n",
"\n",
"3) Fragments with a perigee of less than about 100 km will encounter so much air resistance that they will never make it back to apogee, and will deorbit in less than one period. This explains the decay objects on the bottom left of the graph (purple and orange points) and the progessive drop in apogee as the period gets smaller.\n",
"\n",
"\n",
"\n",
"#### Iridium 33 and Kosmos-2251\n",
"On 10 February 2009, the Iridium 33 satellite collided with Kosmos-2251 causing massive debris clouds to form. To see if Cesium could be used to visualize this impact, the TLE data was gathered for the satellites just prior and after the collision. The resulting simulation successfully showed the two satellites paths intersecting in the artic circle.\n",
"\n",
"\n",
"satellite_czml
python package