test_unitSpacecraftLocation

test_unitSpacecraftLocation.test_spacecraftLocation(show_plots, defaultPolarRadius, defaultPlanet, latitude, maxRange, cone)[source]

Tests whether spacecraftLocation:

  1. defaults planet polar radius to equatorial radius if the polar radius is not set

  2. checks that the zero default planet states are used if the planet is not provided

  3. checks that the planet oblateness is accounted for

  4. checks if the optional sensor boresight axis is properly accounted for

Returns:

test_unitSpacecraftLocation.test_spacecraftLocationColinearAccess(show_plots)[source]

Regression test for issues #644 / #946.

Two spacecraft that are radially aligned (on the same ray from the planet center) at different altitudes have an unobstructed line of sight, so hasAccess must be 1.

Before the #946 fix (commit d432682135), rClose – the closest point on the inter-spacecraft segment to the planet center – was computed from the unclamped line parameter. For a radial alignment that parameter is negative, placing the “closest point” at the planet center (rClose ~ 0), so the rClose.norm() > rEquator gate failed and access was wrongly denied.

This geometry keeps every other access pathway neutral – no planet message (identity orientation at the origin), a spherical planet so zScale == 1, no range cap, no boresight cone, and no sun message – which isolates the rClose computation. The existing test_spacecraftLocation() cases cannot catch this regression: their equal-radius geometry holds the line parameter at ~0.5, inside [0, 1], where the clamp is a no-op.