Orbit Cola

Inspiration

As aerospace engineers, our experiences have taken us across a variety of commercial space companies. Just last summer, two of us worked directly on orbit determination and satellite operations in commercial space. This firsthand experience exposed us to critical gaps in the collision avoidance pipeline—challenges that create inefficiencies, increase costs, and demand better solutions. Enter Orbit Cola.

What it does

Orbit Cola pulls data from the United States Space Command's "Space-Track" database, and uses advanced physics simulations to project the satellite trajectories forward in time in order to compute collision likelihood between any two satellites. Our web-based tool visualizes satellite trajectories and depicts collision risk for satellite operators to assess how to best mitigate risk at low costs.

More specifically, our pipeline gathers Two-Line Element sets from Space-Track [1] and propagates them using an orbit propagator called SGP4 [2]. It then stores this data in an SQL database hosted by Python Anywhere. From here, the pipeline uses the data to investigate potential collision risks and stores those (along with their collision probabilities) in the database as well.

Orbit Cola's website contains many tools useful for satellite operators to look into potential conjunction events, future launches to watch out for, and where current satellites are in space.

How we built it

The bulk of the work for this project was done in Python. The frontend utilizes HTML/CSS and Plotly Dash. These tools were used to create the interactive UI on the website where users can view projected trajectories of satellites around Earth, their ground tracks, and investigate potentially conjunction events in more detail. The backend was built on SQL and Python. The general backend pipeline follows the process outlined here: 1) Use Space-Track's API to gather TLEs for all satellites in Low Earth Orbit 2) Propagate the TLEs using dSGP4 (a modified version of the standard SGP4 propagator designed for quicker multiprocessing) 3) Store the propagated states in the database for visualization and further analysis 4) Use custom conjunction analysis algorithms to determine which satellites are at risk of collision, and calculate the probability of collision using the industry standard Pc calculation 5) Present all this information to a user in a data-driven visual format

Challenges we ran into

One of the most prevalent issues in collision warning and avoidance is quantifying uncertainty in satellite motion induced by measurement and modeling inaccuracies. Computing this uncertainty is critical for national defense as effectively tracking foreign objects in space being a highly sensitive topic. For these reasons, the US Space Command doesn't want this information, nor techniques for obtaining this information, readily available. Thus the challenge. We spent a great deal of time addressing this issue and validating the accuracy of our methods by contriving unit tests on artificial collision scenarios. We hope to continue to refine these techniques with time.

Another challenge is the rate limits imposed by Space-Track when querying data. Users are only able to pull satellite positional data once every hour. On top of that, the satellite data is only updated by the Space Command every 8 hours. Talk about a bottleneck! This required both patience and resourcefulness to validate portions of the code without this data available, along with imposing extra constraints and considerations to prevent accidental over-querying data and being blocked from the Space-Track database.

An additional highly technical challenge is calculating the probability of collision. While it may seem simple at first, the equations utilized to do these calculations require a firm grasp of linear algebra (including projecting a 3x3 matrix onto a 2D plane). Furthermore, the standard model is sensitive to cases with high uncertainty, so developing ways to adjust for that was a challenge in itself.

Finally, the biggest challenge was trying to see what kind of features satellite operators would be interested in. Given the limited amount of time we had to develop our product, it was critical for us to look into features that would be highest impact for satellite operators. We had many discussions along the way about which features are worth devoting man-power to, and the sum total of these difficult decisions is the product you see today.

Accomplishments that we're proud of

We are most proud of our ability to host this website publicly, accurately depicts the (many!) LEO satellites that crowd our near space environment, and showing the paths these objects take throughout their orbit around Earth. We are also proud that we can trace the ground-tracks of the satellites, depicting their paths over Earth's surface as it rotates about its axis. Additionally, we are very proud of our conjunction analyses, presenting potential collisions to satellite operators in an intuitive, visual format.

What we learned

We learned how to host a publicly facing website, constructing both front and back ends. Additionally, we had the opportunity to investigate the theory surrounding satellite collision avoidance. Finally, discussions with potential users gave us deep insights into the satellite industry as a whole.

What's next for Orbit Cola

A major component of this business model would be—once collision detection is finalized—to use advanced off-line planning techniques to automate maneuver design for satellite operators. We also wish to provide a platform to seamlessly connect two satellite operators whose satellites are tagged as being at risk of collision. This full pipeline will offload the work of strategic orbit planning and communication via automation.