Satellite Collision Detection: A Hands-On Coding Experience

This project follows the Engineering Design Process. Confirm with your teacher if this is acceptable for your project, and review the steps before you begin.

Setting Up the Google Colab Environment

1. You will need a Google account. If you don't have one, you can create one here.
2. Download the satellite_collision.ipynb file from Science Buddies. This is the code you will run for this project.
3. Within your Google Drive, click on ‘MyDrive,’ then create a new folder and rename it “satellite_collision”. Inside the folder, upload the satellite_collision.ipynb file.
4. Double-click on the satellite_collision.ipynb file. This should automatically open in Google Colab.

Explanation of the Physics Used in the Code

1. This section explains the physical laws that govern satellite motion. The equations help explain how changes in velocity or altitude affect the simulation’s behavior.
   1. Code block 1a discusses Newton’s Law of Universal Gravitation and Orbital Velocity which were previously mentioned in the introduction section.

   2. Kepler’s Third Law is introduced in this code block:

      1. $$T^2 = \frac{4\pi^2 r^3}{G M}$$
      2. Where T is the time for one full orbit. This law shows that the farther a satellite is from Earth, the longer it takes to orbit.
   3. Code block 1b defines the satellite's initial position and speed before the simulation starts. These values determine the shape and behavior of the orbit: circular, elliptical, escape, or crash, as shown in Fig 2.

   4. Altitude, measured in meters, is the value that sets how high above Earth the satellite starts. You can modify this value to simulate different orbital zones:

      1. 500e3 → Low Earth orbit (2,000 km)

      2. 2000e3 → Higher low Earth orbit (2,000 km)

      3. 20000e3 → Medium Earth orbit (20,000 km)

      4. 35786e3 → Geostationary orbit (35,786 km)

   5. Circular orbital speed (m/s) is given by the following equation:
      $$v_0 = \sqrt{\frac{G M_{\text{earth}}}{r_0}}$$
      
      This formula gives the ideal velocity needed for a stable circular orbit at the given altitude.

   6. You can multiply the circular velocity by different values to simulate non-circular orbits:

      1. 1.1 → 10% faster: Creates an elliptical orbit.

      2. 1.414 → Approx. escape velocity: The satellite leaves Earth's gravitational pull.

      3. 0.8 → Too slow: The satellite falls back to Earth. 

Simulate and Animate a Satellite Orbit 

Here we are going to run a simulation to learn more about the four main types of orbits - circular, elliptical, escape, and crash - as shown by Figure 2.

Figure 2. A 2D visualization of the four main different orbits around Earth. A circular orbit is shown by the green line, elliptical by the purple line, crash orbit by the red line, and an escape orbit by the blue line. The circular orbit is one in which the satellite maintains constant altitude and speed and orbits in a circle due to the balance between Earth's gravitational pull and the satellite's orbital velocity. The elliptical orbit is an elongated circle around Earth, where the satellite’s speed constantly changes. The satellite moves faster when it's closer to Earth and slower when it is farther away, as explained by Kepler's second law. In a crash orbit, the satellite doesn't have enough horizontal velocity to counteract Earth's gravitational pull, causing it to fall to Earth. In contrast, the escape orbit is when the satellite reaches or exceeds escape velocity—the minimum speed needed to overcome Earth's gravitational field—allowing it to break free from orbit entirely and continue traveling into space.

Code block 2 simulates a satellite orbiting Earth using an animation. You can change values like altitude or velocity to simulate different types of orbits (circular, elliptical, crash, or escape trajectory).

You can change altitude which defines the satellite's distance from Earth, and v0 which increases or decreases the satellite's velocity, allowing you to simulate different orbits.

In the simulation, you’ll see a red dot (the satellite) orbiting a blue circle (Earth), with its orbital path traced out in gray. Try adjusting the variables and explore how small changes in speed or position dramatically affect the satellite’s path! For example, increasing altitude creates a larger, slower orbit; increasing velocity stretches the orbit into an ellipse and then once this value hits escape velocity the satellite will break free from Earth's gravitational pull; decreasing velocity leads to a tighter ellipse or even a potential crash orbit scenario.

Simulating and Plotting Real Satellites

1. Code block 3a doesn't run any code, rather its a text block containing URLs where you can access Two-Line Element (TLE) data for simulating real satellites and debris. The code linked above that you will run has satellite data in it, but you can and should replace this with satellites of your choosing. Here are the URLs that are also shown in the code file:
   1. Satellite TLE data:
      1. https://celestrak.org/NORAD/elements/satnogs.txt
      2. http://mstl.atl.calpoly.edu/~ops/keps/kepler.txt
      3. https://www.amsat.org/amsat/ftp/keps/current/nasabare.txt
      4. https://db.satnogs.org/satellites/
      5. https://celestrak.org/NORAD/elements/gp.php?GROUP=active&FORMAT=tle
   2. Space debris TLE data:
      1. https://celestrak.org/NORAD/elements/gp.php?GROUP=cosmos-1408-debris&FORMAT=tle
      2. https://celestrak.org/NORAD/elements/gp.php?GROUP=fengyun-1c-debris&FORMAT=tle
      3. https://celestrak.org/NORAD/elements/gp.php?GROUP=iridium-33-debris&FORMAT=tle
      4. https://celestrak.org/NORAD/elements/gp.php?GROUP=cosmos-2251-debris&FORMAT=tle

2. TLE is a standard data format used to describe the orbit of a satellite. Despite the name, a TLE usually comes with three lines: the first is just the name of the satellite, and the next two are lines of numbers that contain the orbital parameters. These parameters include things such as the inclination of the orbit (how tilted it is relative to Earth’s equator), the eccentricity (how stretched or circular the orbit is), and the mean motion (how many times the satellite orbits Earth in one day). Other values describe the satellite’s current position in the orbit and the exact time the data was recorded. To help visualize what these orbital parameters actually represent, take a look at Figure 3.

Figure 3. Visualization of orbital elements. The inclination (i) represents the tilt of the orbit relative to the reference plane (typically Earth’s equator). The longitude of the ascending node (Ω) and argument of periapsis (ω) define the orbit’s orientation in space. The true anomaly (ν) indicates the satellite’s position along the orbital path at a given time. Together, these angles describe both in-plane and out-of-plane components of orbital motion.

You can find up-to-date TLEs for all kinds of satellites, from the International Space Station to space debris, on the websites like CelesTrak linked above. So when you use a TLE in your simulation, you're not just creating a random orbit, you're tracking the actual path of a real satellite!

Code block 3c loads and visualizes the orbits of multiple real satellites in 3D using their TLE data. It works by extracting key orbital parameters from each satellite's TLE, calculating the shape and orientation of the orbit in space, and then plotting it around a 3D model of Earth.

1. A few important orbital constants are defined:
   1. mu: Earth’s gravitational constant, used to calculate orbital size
   2. r: Earth’s radius (approximate, in km)
   3. D: Length of a sidereal day (the time it takes Earth to rotate once relative to the stars)
2. The plot_tle() function takes a dictionary of satellites and their corresponding TLEs, calculates each satellite’s orbit, and plots it in 3D. Inside the function, it loops through each satellite in the dataset. For each one, it reads the two TLE lines and begins extracting the relevant information. From the second line of the TLE, the function pulls out key orbital elements:
   1. Eccentricity, which shows how stretched or oval the orbit is
   2. Inclination, the tilt of the orbit relative to Earth’s equator
   3. RAAN (Right Ascension of the Ascending Node), which defines the orbit’s orientation around Earth
   4. Argument of perigee, the point where the satellite is closest to Earth
   5. Mean motion, used to calculate the size of the orbit
   6. Using those orbital values from the TLE, the function first calculates the semi-major axis (the longest radius of the elliptical orbit) and then calculates the semi-minor axis (the shortest radius) and the linear eccentricity (the distance between the center of the orbit and the center of Earth). To orient the orbit correctly in 3D space, the function applies a series of rotations using transformation matrices. The inclination sets the tilt of the orbit relative to Earth’s equator, RAAN (Right Ascension of the Ascending Node) rotates the orbit around Earth’s axis, and the argument of perigee determines where the satellite is closest to Earth within its orbit. Together, these steps turn a flat 2D orbit into a realistic 3D path that shows how the satellite actually moves around Earth.
3. The code generates 100 points around each satellite’s orbit, rotates them into the correct 3D orientation, and stores them as x, y, z coordinates. These points are then plotted to create each satellite’s orbit path, with labels showing their names. At the center of the plot, a blue wireframe sphere represents Earth. This wireframe uses polar coordinates to create a globe made of grid lines, giving a clear 3D visual without solid shading. At the end, a dictionary of real satellites and their TLEs—covering amateur radio, Earth observation, and university missions—is passed into the plot_tle() function. The result is a full 3D visualization of multiple satellite orbits around Earth. You’ll see a labeled, blue wireframe Earth with accurately shaped and tilted orbital paths based on real-world data. It’s a powerful way to see how just two lines of TLE data can be transformed into a detailed view of how satellites move through space.

Simulating Satellite Collisions

Code Block 4 introduces the concept of satellite collisions by first simulating a hypothetical one. 

1. In this example, we define three different satellite orbits: one in the XY plane (a circular orbit along the equator), one in the XZ plane (a perpendicular orbit), and one in a 45° inclination tilted plane.
2. Once you’ve run the code and seen how a collision plays out, you can move on to predicting real ones. Just replace the sample TLE data with two satellites of your choice using the TLE sources linked earlier, and the simulation will show whether those satellites are on a collision course.
   1. To work with real satellites, refer back to:
      1. Code Block 3b: for installing the Skyfield library, which allows you to parse and propagate real satellite orbits from TLE data.
      2. Code Block 3c: for an example of how to load, parse, and plot TLE data using the tle_data dictionary.

Code Block 5b is a satellite collision risk scanner that evaluates how close two real satellites — CAS-4A and CAS-4B — might get to each other. 

1. It does this by simulating many orbital positions for CAS-4B and estimating collision risk.
2. Several key functions are used: 
   1. calculate_satellite_positions() gets position and velocity from TLE data using sat.sgp4(),
   2. calculate_relative_position_velocity() subtracts the satellites’ position and velocity vectors to get their relative distance and speed which is key for assessing how close they are and how fast they’re approaching each other,
   3. calculate_distance() finds how far apart they are in space,
   4. estimate_collision_risk() uses that distance and their relative speed to calculate a risk score.
3. A collision warning is triggered if the distance between the two satellites drops below 10 km. CAS-4A uses real TLE data, whereas CAS-4B is slightly modified by adjusting its Mean Anomaly, which is the angle that indicates where the satellite is along its orbit, starting from the closest point to Earth (perigee). To explore how this affects potential collision risk, the code scans CAS-4B’s Mean Anomaly across a small range (±0.1°), using 1000 small steps. For each step, a new TLE is generated, and the code calculates the positions, velocities, and distance between the satellites. It keeps track of the closest approach found during the scan. After the process, the output shows the Mean Anomaly that resulted in the closest distance, the minimum separation, and a collision risk score where 0 means no risk and 0.5 or higher signals high risk. A graph is also generated showing how the distance changes with Mean Anomaly, with a red line marking the closest point. In this simulation, the satellites come within 1.5342 km at 172.8746°, with a risk score of 0.78, indicating a high chance of collision.

1. 1. Note: Your results may vary depending on when you run the code, because TLE data is dynamic and reflects current satellite positions. In one example run, the satellites came within 1.5342 km with a risk score of 0.78. On your run, the minimum separation may differ — for example, 0.0119 km with a risk of 0.0044 — and that’s expected.
   2. This analysis highlights how small changes in orbital parameters can dramatically affect close approaches — a key insight in satellite traffic management.

4. This analysis is crucial for predicting and avoiding satellite collisions because even small changes in Mean Anomaly, which controls a satellite’s position along its orbit, can significantly impact how close two objects come. By scanning this variable, we can pinpoint potential high-risk alignments and take action before a collision occurs.

Code Block 5c scans the real-time orbital positions of multiple satellites using their TLEs. It compares every possible pair and calculates potential collision risks based on their current distance and relative velocity. In the example, we used a set of 12 satellites, but you can replace these with any TLEs you find online using the URLs provided earlier.

For each satellite pair, the output includes:

1. Propagation status: a numeric code showing if the position and velocity were successfully calculated (0 means success)
2. Position (r): the satellite’s 3D location in space
3. Velocity (v): the satellite’s 3D speed and direction
4. Collision risk: a score indicating how likely the two satellites are to collide

Now it's your time to shine and think like a space engineer!

1. Code Block 5d sets up a realistic collision scenario between two satellites, S-Net A and S-Net B, by slightly adjusting the Mean Anomaly in the TLE data. The code calculates each satellite’s position and velocity, then finds their distance and relative speed. A collision risk score is also calculated, where a score near 1 means a high chance of collision. If the risk is greater than zero, the simulation applies a small avoidance maneuver—by increasing S-Net A’s speed slightly—and checks whether the new trajectory successfully reduces the risk.
2. In this scenario, the satellites pass within 1.21 km of each other at a relative speed of 1.32 m/s, resulting in a collision risk score of 0.0004. After applying the maneuver, the score increases slightly to 0.0033, showing that the change wasn’t effective. Now it’s your turn to take over: how would you adjust the maneuver to better avoid a collision? Try changing the direction or amount of the velocity adjustment, or experiment with modifying other orbital elements in the TLE data—such as the Mean Anomaly, Inclination, or RAAN. Even small changes can shift the satellites enough in time or space to reduce the risk of a close encounter.