Simulated Ring Navigation Model
Overview
NavModelRingsSimulated is the
simulated-image variant of the ring navigation model. It renders a ring system from
operator-supplied edge radii and shading parameters instead of from a SPICE-driven
catalog, then emits two feature kinds:
a
RING_ANNULUScarrying the rendered template, forRingAnnulusNav;one
RING_EDGEper rendered edge (inner and outer) – a per-vertex polyline with outward radial normals – forRingEdgeNav.
The model overrides instances_for_obs() to build
one instance per ring of a simulated observation; the parent
NavModelRings declines simulated observations, so
the autonomous registry routes simulated frames here.
Theory
Simulated ring rendering paints a stack of catalog-shaped ring edges onto an extended-FOV
image plus mask using image-plane coordinates and operator-supplied shading. The
RingFeature data model carries the per-edge
metadata exactly as in the catalog-driven path; only the rendering pipeline differs
(pixel-space here vs. backplane-based for the real model).
The rendered template is the
RING_ANNULUS feature payload the
correlation technique navigates against. The per-edge RING_EDGE polyline extends the
simulated ring to the edge-fitting technique: each rendered edge mask
(compute_border_atop_simulated()) is sampled into a vertex
polyline with outward radial normals and a curvature-based is_straight_line flag, and
RingEdgeNav fits two curved arcs to
constrain the offset in both axes. The simulated ring’s geometry is operator-known by
construction, so the simulated path is the calibration regime – a developer can probe the
ring pipelines with rings whose true offset is known to the pixel.
Restrictions and assumptions
The operator must supply finite per-edge radii and a finite shading distance.
The simulated rings carry no per-image noise or PSF smearing; the operator’s downstream noise-injection pipeline supplies those.
The ring system is rendered in image-plane coordinates: edges are concentric ellipses about the operator-supplied centre. More elaborate orbit geometry (precession, nodal regression) requires the catalog-driven path.
Sources of uncertainty
The simulated annulus has no measurement uncertainty by construction. The downstream technique’s reported covariance reflects only the correlation-curvature CRLB at the chosen NCC peak.
Configuration
The simulated ring model consumes no YAML configuration of its own; every parameter comes
in via the per-instance sim_params dict. Expected keys:
name— ring-system label used in metadata.feature_type—RINGLET(bright ring) orGAP(dark gap).center_v,center_u— pixel coordinates of the ring centre.range— subject distance in km.shading_distance— controls the per-edge surface-brightness falloff.inner_data,outer_data— lists of dicts each carryingmode,a,rms,ae,long_peri, andrate_perikeys (catalog-shaped per-edge entries).
Implementation
Source file: src/nav/nav_model/nav_model_rings_simulated.py —
NavModelRingsSimulated.
Public class NavModelRingsSimulated,
base NavModelRingsBase. The class overrides
instances_for_obs() to build one instance per ring
of a simulated observation; the parent
NavModelRings returns an empty list for a simulated
observation, so the orchestrator’s
build_models_for_obs() driver routes simulated frames to
this subclass.
Public methods (autodocumented at nav.nav_model):
create_model()— invokesrender_ring()to render the simulated ring stack, then computes the bounding box and reliability scalars.to_features()— emits the RING_ANNULUS plus one RING_EDGE per rendered edge (inner / outer).to_annotations()— reuses the shared ring annotation helper onNavModelRingsBaseto render per-edge polylines and labels onto the summary PNG.
Inherited NavModel properties:
name,
obs,
metadata.
Call path
Call path traced through
create_model():
Open a logged section. Read the operator-supplied sim parameters off the per-instance dict and the ring-system name.
Build
RingFeatureinstances from the per-edge sim parameter lists. TheRingFeaturedata model is shared with the catalog-driven path so the downstream emission path is identical.Call
render_ring()with the per-edge data, the operator-supplied centre, and the shading parameters. The helper returns the rendered ring-system image plus mask.Compute the per-edge brightness contrast and the per-pixel
border_atopmasking viacompute_border_atop_simulated().Promote the rendered image plus mask from sensor-shaped arrays to extfov-shaped arrays.
Record the predicted centre, the subject range, and the bounding box on the model’s internal state for downstream feature emission.
Call path traced through
to_features():
Construct one
RING_ANNULUSNavFeaturecarrying the rendered template image, the mask, the predicted centre, and aRingAnnulusFlagswith the operator-supplied ring-system name.For each rendered edge, recompute its 1-pixel edge mask via
compute_border_atop_simulated(), sample it into a vertex polyline with outward radial normals, classify it straight or curved, and append aRING_EDGEcarrying aRingEdgePolyline.Reliability on each feature is fixed at
1.0.
Examples
The simulated ring model is consumed by the simulated-image GUI driver
(nav_create_simulated_image). An operator specifies a Saturn-like ring stack —
inner edge radii [74,490, 91,980, 122,170] km, outer edge radii
[91,980, 117,580, 136,780] km, shading distance set per the per-image illumination
geometry — and the simulator renders the corresponding extended-FOV image plus annulus
mask. The downstream
RingAnnulusNav correlates the
template against an injected synthetic-noise image and recovers the operator-known
(0, 0) offset within sub-pixel. The operator uses the residual to validate
per-instrument ring-rendering assumptions without a real ring image.