Remix.run Logo
deddy 2 days ago

Need to do a full read in more depth but it looks like they used a collision cross section of A=300 m^2, which is a little conservative but not insane given that the current Starlink v2 mini has about 90-120 m^2 of total surface area on its solar arrays. [1] The solar arrays are the largest part of these spacecraft by far and what defines the “collideable” area. A combined hard-body radius of 2 x 120 = 240 is in the ballpark for starlink-on-starlink collisions.

However most of collisions of concern are going to be starlink-on-debris, which is back down at the 120 m^2 level. Starlink already self screens for collisions and uplinks the conjunction data messages over the optical intersatellite link backbone or over their global ground station network.

If they aren’t able to talk to their satellites regularly from somewhere, you’re right we have MUCH bigger things to worry about on the ground.

[1] https://spaceflightnow.com/2023/02/26/spacex-unveils-first-b...

2 days ago | parent | next [-]
[deleted]
brookst 2 days ago | parent | prev [-]

And wouldn’t the solar panels have less cross section than the satellite bodies, so even an apparent collision might just be a very near miss? (Honest question, not rhetorical, could be I’m wrong)

deddy 2 days ago | parent | next [-]

This is confusing terminology in the field, but you generally talk about the cross sectional area in the plane of the conjunction (https://www.space-track.org/documents/SFS_Handbook_For_Opera...) to calculate the probability of collision.

It’s a conservative definition in the field. It’s generally defined as the hard body radius: take the smallest sphere centered at the center of mass that would entirely enclose the object, then use the maximum cross section of that sphere to define the potential “area” of the colliding object.

Maybe put more simply, it’s the worst case area size / orientation you could be looking at. So yes. Solar arrays have a narrow cross section from the side but looking at them head-on (which is the angle used for Pc calculations) they’ll be very large.

HPsquared 2 days ago | parent [-]

Shouldn't they try and take some kind of probabilistic average area, rather than worst-case? I assume this is a statistical analysis.

deddy 2 days ago | parent [-]

It depends on what you're going for.

Generally people really don't want collisions due to cascading effects, so they take the worst-case probability of collision found with bounding assumptions. Additionally, while often all these vehicles have active attitude (orientation) control, sometimes they go into safe mode and are spinning (often spin stabilized to point at the sun), so it will clear the entire potential radius while rotating.

Also how do you define the probabilistic average area for a space object that you don't know how it's control system works or what it's been commanded to do / point at. Yes we can make some pretty good assumptions for things like Starlink, but even those do take safemodes occasionally.

So It's an engineering judgement call on how to model it. It's hard to get a probabilistic average for attitude that you can confidently test and say is "right", it's a lot easier and conservative to take the worst-case upper-bound. That's at least not-wrong.

notahacker 2 days ago | parent | next [-]

Worth adding that the actual collision avoidance manouevres Starlink (and other satellites with propulsion) makes are based on more conservative assumptions

The papers assumptions lead to the conclusion that with no manouevres, we'd see a catastrophic crash between two or more satellites in LEO within 2.8 days. To be on the safe side, Starlink did over 144000 in the first six months of the year (and based on historical doubling rate, will probably be doing 1000 per day by now)...

2 days ago | parent | prev [-]
[deleted]
rzimmerman 2 days ago | parent | prev [-]

Yeah the solar array on Starlink is held perpendicular to the velocity vector, so the cross section relative to the colliding body will invariably be smaller than the worst case.