Satellite Collision Avoidance Technology
Starlink satellites maneuver >148,000 times to avoid collisions
In its latest semi-annual report to the FCC, covering the timeframe of June-November 2025, SpaceX reported it made 148,696 collision-avoidance maneuvers. Autonomous on-board systems orchestrate the vast majority of these avoidance maneuvers. In this post we explore the core concepts and technologies deployed for automated collision avoidance in today’s satellite constellations. This is a follow up post to our previous post on Space Situational Awareness (SSA), of which collision avoidance is core capability.
*Note, this post is not specifically about SpaceX Starlink and includes a few references to Starlink systems where appropriate.
In the lingo of space flight operations, the probability of a collision is called a conjunction - a predicted close approach between two objects in orbit. A conjunction is not a collision itself, but a warning that two objects are expected to pass near each other closer than a preset safety distance. Satellite flight dynamics and operations teams use conjunction predictions to assess the probability of collisions and, if that probability is too high, plan and execute a small orbit change (a maneuver to alter the satellite’s Δ v, delta v, velocity) to keep the satellite safe.
Satellite Collision Avoidance Systems - Core Components
Current automated satellite collision avoidance, or conjunction assessment (CA), systems employ a three-stage process of screening, probabilistic risk assessment and autonomous maneuver planning or “mitigation”.
Phase 1: Screening
Spacecraft operators supply spacecraft orbit data, called ephemerides, to the USA Space Defense Squadron where the data is ingested and compared to a master catalog of all objects in orbit This catalog is maintained by the U.S. Space Force. Ephemerides are detailed descriptions of where a spacecraft is in space at different times, and how fast it is moving. Think of it as the “flight schedule and track” of a spacecraft. The orbit data is screened for close approaches and used to compute collision probabilities.
Phase 2: Risk Assessment
The screening data is then packaged into standardized files called Conjunction Data Messages (CDMs) that describe predicted close approaches and satellites state covariances. Covariances are estimates of errors in a satellite’s position and velocity and has three values for position (x, y, z) and three values for velocity that are presented as a matrix.
The CDMs are then sent to the spacecraft operator who is responsible for analyzing the data, performing risk analysis, and executing collision avoidance (mitigation) steps if needed. Most space operators compute a “Probability of Collision” or Pc with a chosen threshold of action to assess if mitigation is warranted. Pc is computed using sophisticated analytical and data sampling methodologies and is used to model “virtual” encounters as a core aspect of the analysis.
As you can imagine this conjunction/risk assessment is a highly specialized and complex undertaking. While commercial space operators have developed and operate in-house risk assessment capabilities, there are several government sponsored and commercial third party providers who offer specialized services. Examples include NASA’s Conjunction Analysis Risk Assessment (CARA) program, NASA Johnson Space Center Flight Operations Directorate, and the European Union Space Surveillance and Tracking (EUSST) program.
Phase 3: Mitigation
If a Pc or object approach distance exceeds operator thresholds, mitigation options are evaluated and a plan is chosen. To assess options, an automated planner searches candidate maneuvers (time, direction, magnitude) to minimize risk while preserving mission and flight objectives. Maneuvers must be screened and approved before execution to minimize the potential for creating additional close approaches. Approved maneuvers are uploaded or autonomously commanded, then after completed, the system rescreens using updated spacecraft position states to re-assess conjunction risks and Pc.
While the growing number of avoidance maneuvers is designed to make orbital operations safe, maneuvers can also have negative effects on predictions of future collisions. A study by the Pennsylvania-based Commercial Space Operations Center (COMSPOC), published last year, found that every collision-avoidance maneuver throws off satellite path forecasts for several days. In the aftermath of maneuvers, satellites’ actual positions may differ from their forecasted ones by up to 25 miles (40 kilometers), potentially making collision predictions inaccurate.
Autonomous onboard collision avoidance
Operators of large-scale satellite constellations (like SpaceX Starlink) deploy an automated collision avoidance system that can plan and execute maneuvers on-board every spacecraft. Here is an overview of the typical core components and capabilities of the multi‑tiered software architecture that underlies these collision avoidance systems. (these details are typical and are not necessarily specific to Starlink)
Navigation and state estimation – an onboard navigator module (usually a Kalman filter) combines data from GPS and other sensors to produce precise estimates of position, velocity, and attitude in real time – aka the “state vector” of the spacecraft. The state data also includes estimates of possible errors or “covariance”. The spacecraft state is fed into the conjunction logic in real time.
Conjunction logic, catalog and external inputs – conjunction logic are the rules and algorithms used to detect, evaluate, and respond to close approaches between a spacecraft and other objects. An External Catalog Application (or equivalent) maintains an onboard catalog of high‑risk objects derived from ground catalogs and CDMs and is on-board catalog is updated periodically.
Autopilot, guidance and control – an autopilot application performs autonomous conjunction assessment and maneuver analysis to turn candidate maneuvers into feasible thrust sequences. Guidance and control software enforce mission and flight constraints (trajectories, attitude pointing, formation geometry for constellations, etc.) while minimizing Pc and future conjunctions.
Supervisor/commander and mission manager – a supervisor or mission‑manager layer coordinates between the autopilot, navigation, and catalog applications. It triggers Pc checks at configurable times and handles go/no‑go maneuver decisions and timelines. The mission manager also coordinates with ground based Space Traffic Management (STM hubs) that synchronize multiple catalogs, planned maneuvers, and risk estimates across multiple operators to avoid conflicting autonomous responses. STM hubs manage fleets of satellites vs. managing individual satellites.
Ground based support systems - AI/ML technologies
Onboard autonomous systems are impressive for sure, and they require numerous support systems that are ground based. Here are few examples:
High‑volume screening and policy enforcement usually remain ground‑centric. Operators of large fleets of satellites typically run continuous screening on their fleets against global catalogs, available CDMs and send maneuver recommendations up to spacecraft. These processes involve scalable orbit propagation and management, covariance management (errors in a satellite’s estimated position and velocity), and prioritization (triaging) thousands of daily close call alerts down to a manageable number.
Coordinating with NASA’s Conjunction Assessment Risk Analysis (CARA) program is an example of these activities. NASA CARA predicts and evaluates close approaches between NASA’s uncrewed spacecraft and other space objects, then helps plan collision-avoidance maneuvers when needed, and is tasked to assist satellite operators in designing and executing mitigation maneuvers.
AI/ ML for criticality and maneuver recommendation. Systems like the European Space Agency’s AUTOCA (Autonomous Collision Avoidance) system is an AI‑driven decision support tool that ingests conjunction data messages for a satellite, and leverage AI/ML models to estimate conjunction criticality and predict Pc evolution over time and autonomously recommends if and how to perform a collision avoidance maneuver, particularly for large satellite fleets. The AI/ ML components operate on data extracted from CDMs (relative geometry, covariances, object class) and feed into rule‑based logic that compares predicted risk to operator policy thresholds.
How are maneuver Go/No Go decisions made?
Automated collision avoidance sounds like a no brainer – right? Deciding if/when/how to maneuver a satellite is not as straight forward as you might think. Ultimately deciding to maneuver is based on a bone fide quantified risk where important metric(s), usually a high probability of a collision Pc (geometric miss distance), crosses predefined thresholds within a specified time window, subject to spacecraft health, mission, and operational constraints. Assessing the various constraints is a complex multi-variate analysis. Further, any maneuver “burn” must be pre-approved and carefully planned to ensure the maneuver is optimized and does not result in additional Pc.
Bear in mind that the more maneuvers a satellite makes the faster it use up its thrust propellant, resulting in a shortening of its operational life, potentially leading to an earlier “de-orbiting” than is desired.
Here is a simplified overview of the core criteria used to decide to maneuver…
Probability of collision and miss distance – software computes probability of collision, Pc, using the current satellite state estimate and covariance for both objects with a maneuver considered if Pc exceeds a set limit and/or the predicted miss distance is below safety buffers.
Satellite operators are on the hook to establish and enforce these limits to ensure satellite operations are safe and secure. Pc limits are often time‑dependent (aka the shorter the time window to “closet approach”, the stricter the limit) and usually vary by object type: crewed satellite, space station, high‑value spacecraft, or random space debris.
An important criterion is Time to Closest Approach (TCA) window. Automation typically defines “decision windows” before TCA occurs and only considers maneuvers if a feasible burn can be executed successfully and settled before that time. Another way to think of this is that an assessment of the “last‑safe‑burn time” is needed. If the system is inside the TCA window without a viable solution, rules usually fall back to “do not maneuver” to avoid making things worse with late, or poorly orchestrated burns.
Navigation state and continuous assessment of uncertainty – onboard automation maintains a best‑estimate orbit plus covariance (error/uncertainty). High uncertainty can both inflate Pc and temporarily suppress maneuvers until more tracking data reduces ambiguity and uncertainty. Some implementations use “consider” parameters or covariance inflation when recent maneuvers or limited tracking make predictions less reliable, which directly affects the maneuver/no‑maneuver decision.
Conjunction data and context – as described above, the onboard software receives or maintains a list of candidate conjunctions with data from CDMs (from uplinked messages or onboard propagation) and periodically recomputes risk for conjunction. It also checks metadata such as whether the other object is maneuverable, whether there are multiple close approaches in a cluster, and whether prior planned maneuvers already mitigate the event under consideration.
Decision logic structure – rule‑based “gates” – most space flight implementations use a layered rule set: first, filter out obviously benign events; then apply numeric thresholds on Pc, both radial and along‑track separation, and timing; finally, apply mission and safety constraints before authorizing a maneuver. Radial separation refers to the difference in distance from the center of earth between two spacecraft – which spacecraft is higher or lower relative to the other. Along-track separation refers to the distance between spacecraft measured forward or backward along their flight path, aka who is ahead or behind the other and by what distance.
Safety constraints/rules that are typically considered include:
enforce minimum separation (like commercial aircraft) in radial and along‑track directions
spacecraft fuel and engine duty‑cycle limits – is there enough fuel and can the engine execute the burn effectively
enforce “no‑burn” periods, such as during critical payload operations or pre-designated safe‑modes
Optimization/assessment of candidate burns – if a conjunction passes the rule gates, the automation generates several candidate maneuvers (varying time, direction, and magnitude) and scores them against a cost function combining residual Pc, and Δv, the desired change in a spacecraft’s velocity to perform a maneuver. Δv changes to spacecraft velocity is one of the core design and navigation parameters for any mission, because it directly links maneuver capability, propellant mass, and mission feasibility. Navigation burns are also assessed against the impact on future operations, and potential creation of new conjunctions.
The system then selects a solution that drives Pc below a lower “clearance” threshold while staying within Δv and operational limits. If no solution candidate satisfies these constraints, the automation may choose to stand down on executing a maneuver and monitor status only.
Constraints for safety, mission, and human‑in‑the‑loop considerations
A variety of spacecraft systems’ health and configuration checks are executed before any burn operation. Confirmations of propulsion health, attitude margins, and that required sensors and actuators are fully operational are completed. If any of these systems fail a check, usually the maneuver is blocked and flagged for human review. Some systems enforce “hold‑downs” after recent anomalies or large burns, meaning the automation can compute but not execute new maneuvers without human operator approval.
Human operator policies and coordination
Best‑practices for satellite operations recommend that even autonomous systems follow operator‑defined policies such as always communicate planned maneuvers, avoid simultaneous autonomous responses by multiple spacecraft, and respect agreed to “right‑of‑way” conventions when other operators are involved. Many current autonomous architectures let onboard software decide and stage a maneuver but leave a short veto window for ground personnel to approve/deny a maneuver, unless a rapid response is required.
What about situations when automation decides not to maneuver
As Pc gets updated regularly, if it shows improving geometry where the Pc is trending downward or dominated by catalog uncertainty, the logic may deliberately wait for more data rather than maneuver prematurely. At very high relative speeds or grazing geometries (the spacecraft’s path has a very shallow angle relative to another object) small burns may not materially reduce risk, so the automation may conclude that no maneuver is the safest option.
Automation logic will penalize maneuvers that push the satellite into neighboring planes or orbital areas where conjunction rates are higher, even if the maneuver would fix the immediate event. If a burn would consume disproportionate Δv relative to the spacecraft’s remaining lifetime, policies can force the system to accept a lower Pc risk instead.
Which onboard sensors trigger a maneuver decision
For satellite collision avoidance, no single “proximity sensor” like radar or lidar normally triggers the maneuver decision. Triggering maneuvers involve navigation and tracking data from a small set of core onboard sensors plus uplinked space object catalog data.
Primary onboard sensors can include GNSS receivers, GPS, and/or Galileo that track and provide the satellite’s precise position and velocity, which the onboard navigation filter turns into an orbit state and covariance.
A GNSS (Global Navigation Satellite System) receiver is a specialized electronic device that “listens” to navigation signals from multiple of position/location systems like GPS, Galileo, GLONASS, and BeiDou. GNSS times signals from several satellites, to calculate their own position, speed, and very accurate time. GNSS units have large, high‑quality antennas and low‑noise electronics, giving cleaner signals and less error from reflections and interference than systems like GPS. GNSS receivers can routinely reach sub‑meter to centimeter‑level accuracy when combined with error correction.
GPS is the US satellite navigation system used to support a multitude of military, commercial aviation, autonomous vehicles, mobility (phone) and consumer products and services. GPS satellites broadcast timed radio signals that let compatible receivers figure out their position anywhere on or near Earth. Accuracy of GPS systems in space is typically 10 meters horizontally and 20 meters vertically in low Earth orbit (LEO) but can be enhanced with specific optimizations. GPS is useful primarily for LEO only, as GPS signals weaken significantly beyond 1,800 miles.
Galileo is Europe’s satellite navigation system, similar to GPS but designed for very high accuracy and civilian control.
Inertial Measurement Unit (IMU), gyros and accelerometers measure attitude rates and non‑gravitational accelerations (from thrusters, atmospheric drag), improving short‑term knowledge of how the orbit is changing. Accurate modeling of these variables/changes tightens the uncertainty (covariance), which directly affects computed collision probability and therefore whether a maneuver is triggered.
Attitude‑determination sensors including star trackers, sun sensors, magnetometers capture the spacecraft’s orientation so the system can correctly project thrust directions and non‑gravitational forces into the orbit frame. Developing accurate attitude knowledge ensures that the predicted effect of any candidate maneuver on future conjunctions is reliable, which is necessary before autonomously authorizing a burn.
Finally, system health and configuration monitor telemetry from the propulsion system (tank pressure, valve status), satellite power system, and attitude‑control sensors also acts as a gate, meaning if they report out‑of‑limits conditions, or a malfunction, the automation will block a maneuver even if the conjunction risk is high.
Satellite operators are responsible for defining sensor thresholds that initiate onboard maneuvering and defining numeric limits on navigation quality and risk metrics, and these are what the onboard autonomy watches. Quality and risk metrics include GPS/GNSS estimation quality such as maximum allowable position error, velocity error, or covariance trace before an autonomous maneuver is allowed.
Operators tune sensor threshold values depending on satellite type and capabilities, mission objectives, acceptable risk, propulsion capability, and satellite constellation density. Typically, these values are not published publicly. Even within a satellite fleet, thresholds can differ between high‑value spacecraft, short‑lived smaller satellites, and deorbiting vehicles.
How does a satellite execute a burn to alter its position in space
Changing the orbit of a spacecraft is accomplished with an orbital maneuver called a “burn”. A satellite executes a burn by firing its thrusters in a precisely timed direction to change its velocity, or delta-v (Δv), which modifies its orbit. Even small changes in speed or direction can significantly reshape a craft’s orbit because orbital paths are set by the satellite’s position and velocity vector around the central body – aka usually the earth.
Space flight operations teams, or as discussed in this piece autonomous flight systems, determine and compute the exact Δv vector (magnitude, direction, and timing) needed to get from the current orbit to the target orbit. This typically involves choosing a maneuver point such as perigee, apogee, or a node where burns are most efficient for raising/lowering altitude or changing inclination.
There are three basic ways a spacecraft can apply thrust by firing its engine(s) to change its orbit: prograde, retrograde, and out‑of‑plane burns. These describe direction of thrust relative to the current path.
Prograde fires the engine in the same direction the spacecraft is already moving along its orbit, akin to stepping on the gas pedal in a car, to speed the spacecraft up and raises the opposite side of the orbit
Retrograde fires the engine opposite the direction of exiting motion, akin to applying the brakes in a car, it slows the spacecraft down and lowers the opposite side of the orbit
Normal/Out‑of‑plane thrust is pointed above or below the orbital plane instead of forward or backward along the path. This changes the tilt (inclination) of the orbit, like tipping a hula hoop to a new angle in space, without raising or lowering the average height of the orbit.
At the planned time, the spacecraft propulsion system opens valves and ignites the thruster(s) (chemical, electric, or cold‑gas), maintaining attitude control so thrust stays aligned with the commanded vector for the duration of the burn. Once the required burn duration or Δv is reached, the thrusters shut off, leaving the satellite coasting in its new orbit defined by the updated position and velocity. Ground controllers and on-board navigation then carefully track the spacecraft, estimate the achieved orbit, and, if needed, schedule small cleanup burns (trim maneuvers) to fine‑tune its position.
Types of spacecraft propulsion systems
Satellite thrusters (on-board maneuvering engines) fall into a few major families that trade off thrust level, efficiency, complexity, and propellant type.
Chemical thrusters create force by burning propellant and expelling hot gas at high speed through a nozzle; they can be monopropellant – aka single fluid design usually with hydrazine fuel, or “green” alternatives (usually nitrous oxide-based), or bipropellant, fuel plus oxidizer, systems. Chemical thrusters deliver relatively high thrust and are common for orbit raising, major attitude changes, and fast maneuvers, but their efficiency is modest, so they consume more propellant mass for a given total Δv.
Cold‑gas systems store an inert gas, often nitrogen or sometimes compressed air or similar benign gas, in a tank and release it through a simple valve and nozzle without combustion. These systems are very simple, clean, and highly reliable, and are often used for small satellites and for attitude control—but they provide low levels of thrust, meaning they quickly run out of useful Δv for larger/long missions.
Electric thrusters use electrical power (from solar arrays or batteries) to accelerate propellant ions or plasma to very high exhaust velocities, achieving much higher specific impulse than chemical or cold‑gas systems. Common electric types include ion engines and Hall‑effect thrusters, which offer extremely efficient long‑duration thrust ideal for station‑keeping, slow orbit raising, and deep‑space cruising. The downside of these systems is their need for substantial onboard power.
*Note: Nuclear - NASA has been exploring the potential for Nuclear Thermal Propulsion since the 1060’s. While nuclear systems are viewed as potentially viable and powerful these remain experimental technologies with NASA continuing to work towards an in-orbit demonstration….
Wrapping up
Operating large constellations of satellites would not be possible without sophisticated conjunction management systems powered by autonomous systems. Collision avoidance starts with establishing awareness of where everything is in space and where it is headed aka Space Situational Awareness. Hopefully this post helps illuminate the core processes and technologies being deployed to keep spacecraft where they belong – coasting safely in their designated orbits around the earth.
Please share your thoughts via the Comments section for this post or open a new SubStack chat thread … and please forward this post to your friends and colleagues. Until next time!