Line Of Sight Access — Robotics/Spacecraft Dynamics
Robotics/Spacecraft_Dynamics/Line_Of_Sight_Access · 2 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Line of Sight Access
Robotics / Spacecraft Dynamics
Whether a source can see a target past the body they orbit: 1 when the straight segment between them stays outside the central body, 0 when any part of it passes strictly inside. The body is the ellipsoid of equatorial radius a and flattening f, b = a(1 − f). Scaling x and y by 1/a and z by 1/b makes it the unit sphere: with s′ and t′ the two scaled positions and d = t′ − s′, the segment's point nearest the centre is at k = −(s′·d)/(d·d), clamped to [0, 1], and the answer is 0 when |s′ + k·d|² < 1 and 1 otherwise.
Ports
- r_source – the source's position, one [3,1] column [x; y; z] in the central body's body-fixed frame (z along its spin axis), from its centre, in the chosen Units.
- r_target – the target's position, [3,1], the same frame and unit.
- access – [1,1]: 1 when the two can see each other, 0 when the body is in the way.
Parameters
- Central Body – the body in the way, and with it a and f:
- Earth – 6378136.3 m, f = 1/298.257223563. The default. Note the radius is the EGM one, not WGS84's 6378137.
- Moon – 1738200 m, f = 0.0012.
- Mercury – 2439700 m, a sphere.
- Venus – 6051800 m, a sphere.
- Mars – 3396200 m, f = 0.00589.
- Jupiter – 71492000 m, f = 0.06487.
- Saturn – 60268000 m, f = 0.09796.
- Sun – 696000000 m, f = 5×10−5.
- Units – the length unit of both positions:
- Metric (m) – metres. The default.
- Metric (km) – kilometres.
- English (ft) – feet, 0.3048 m.
- English (M) – nautical miles, 1852 m.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The body's two radii, already in the chosen unit, are baked into the emitted code rather than published as tunable parameters.
The three hardware targets compute in real inside a
function and are simulation-only; only the ports are Q16.16. Those ports
hold nothing beyond about ±32767, so positions near the Earth need
kilometres or nautical miles, never metres or feet, or the fixed-point
conversion wraps. A pair of positions within about 10−5 of the
grazing case can come out the other way in hardware than in software.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibsatdyn/Line of Sight Access. Central Body →
sourceCentralBody and Units → units, both
1:1 and therefore lossless. Always written, with no configuration behind them:
sourceFrame and targetFrame Fixed-frame,
useSourceCentralBodyForTarget on, timeSrc Dialog, both
fields of view off, the Earth and Moon occulters off, and one access output.
Simulink's Uranus, Neptune and Custom bodies do not cross (a Custom body adds a
pole-orientation input port there), and its ICRF and latitude/longitude/altitude
frames do not either: in ICRF the block converts to the body-fixed frame through
precession and nutation for a date, which this block does not model. The
Simulink block defines no SampleTime, so the rate stays on the ICore
side.
Notes
- Algebraic and stateless: the output depends only on this sample's inputs.
- Not linear, so the block carries no state space and model reduction correctly reports it as unmergeable.
- Inside the body means blocked: a source or a target inside the body has no access, even pointing straight out, and neither do two points that are both inside.
- A point on the surface sees straight up and along its own tangent plane; a chord between two surface points is blocked. Measured on the Simulink block, which agrees on every case.
- Verified against R2026a: on the parity rig's 500 samples (Mars in km, the source ~200 km above latitude 80° and the target a line through the body) this block's arithmetic and the Simulink block agree on every sample, 41 % of them with access and 20 of them decided by the flattening.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Spacecraft_Dynamics/Line_Of_Sight_Access |
| family | Robotics/Spacecraft_Dynamics |
| solver environment class | ICoreBlock_0_Robotics_1_Spacecraft_Dynamics_2_Line_Of_Sight_Access |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Spacecraft_Dynamics/Line_Of_Sight_Access/ICoreBlock_0_Robotics_1_Spacecraft_Dynamics_2_Line_Of_Sight_Access.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Spacecraft_Dynamics/Line_Of_Sight_Access/ICoreBlock_0_Robotics_1_Spacecraft_Dynamics_2_Line_Of_Sight_Access.h |
| default size on canvas | 160 × 80 px |
| ports at insert | 2 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | r_source |
| 2 | in | ICoreDouble | r_target |
| 3 | out | ICoreDouble | access |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Central Body | comboOf(bodies, 8, "Earth") | sourceCentralBody |
Units | comboOf(units, 4, "Metric (m)") | units |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | aerolibsatdyn/Line of Sight Access |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | sourceFrame = Fixed-frame, targetFrame = Fixed-frame, useSourceCentralBodyForTarget = on, timeSrc = Dialog, sourceUseFOV = off, targetUseFOV = off, sourceIncludeEarth = off, sourceIncludeMoon = off, outputIndividualAccess = off |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Central Body | sourceCentralBody | Earth → Earth, Moon → Moon, Mercury → Mercury, Venus → Venus, Mars → Mars, Jupiter → Jupiter, Saturn → Saturn, Sun → Sun |
Units | units | Metric (m) → Metric (m), Metric (km) → Metric (km), English (ft) → English (ft), English (M) → English (M) |
Caveat (shown to the user): both positions cross in the central body's BODY-FIXED frame: sourceFrame and targetFrame are always Fixed-frame, because in ICRF the Simulink block rotates into the body-fixed frame through precession and nutation for a date (measured: a grazing threshold moves 67 m between 2000 and 2031) and this block has no date. Uranus, Neptune and Custom do not cross -- a Custom body adds a pole-orientation input port there. English (M) is the nautical mile on both sides. The Simulink block has no SampleTime, so the rate stays on the ICore side
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Line of Sight Access -- can the source see the target past the central body? S = the source's position, T = the target's, both in the central body's BODY-FIXED frame and from its centre. The body is the ellipsoid of equatorial radius a and flattening f, b = a(1 - f). Scaling x and y by 1/a and z by 1/b turns it into the unit sphere, and the question becomes where the scaled segment comes nearest the centre:
s' = (Sx/a, Sy/a, Sz/b), t' = (Tx/a, Ty/a, Tz/b), d = t' - s' k = -(s'.d)/(d.d), clamped to [0, 1] (k = 0 when the two points coincide) access = 0 when |s' + k d|^2 < 1, else 1
MEASURED AGAINST THE AEROSPACE BLOCKSET'S Line of Sight Access, R2026a, 2026-09-11, by sweeping grazing segments through the real block and bisecting where the answer flips:
⚠ THE EARTH IS 6378136.3 m, NOT WGS84's 6378137. The equatorial threshold lands at 6378136.300000003, the polar one at 6356751.6006133 = 6378136.3 * (1 - 1/298.257223563): the EGM radius with the WGS84 flattening. The other bodies, the same way: Moon 1738200 m, f 0.0012; Mercury 2439700, sphere; Venus 6051800, sphere; Mars 3396200, f 0.00589; Jupiter 71492000, f 0.06487; Saturn 60268000, f 0.09796; the Sun 696000000, f 5e-5. Uranus and Neptune are not offered: at their tabulated radii the sweep found no flip at all in the fixed frame, so they are not the axis-aligned ellipsoids the others are, and a guessed shape is not a measurement.
⚠ WHY BODY-FIXED. In its default ICRF mode the Simulink block converts both positions into the body-fixed frame through precession and nutation for the chosen date: the same mid-latitude grazing segment flips at 0.13 m below the ellipsoid on 2000-01-01, 50 m below it on 2024-01-01 and 67 m below it on 2031-07-01. In its Fixed-frame mode the threshold is the same on every date, to 5e-8 m. The bridge therefore always writes Fixed-frame, and a user with inertial positions rotates them first.
⚠ THE EDGE CASES, all measured on the real block:
- a source or target inside the body is blocked, even pointing straight out;
- two points inside the body are blocked, even when the segment between them misses the
centre -- so this is "does the segment pass inside", not "does it cross the surface";
- a point ON the surface sees straight up, sees its own tangent plane, and sees itself;
a chord between two surface points is blocked;
- the minimum elevation angles do nothing to a Fixed-frame asset, on the surface or in
orbit (the arcs were identical at 0 and at 10 or 20 degrees), so they are not configs.
⚠ UNITS SCALE THE RADII ONLY. English (M) is the NAUTICAL mile, 1852 m -- measured, the equatorial threshold in that unit is 3443.918088552906 = 6378136.3/1852, where a statute mile would have put it at 3963.19.
Sample results#
Plotted: vector — Sine Wave, [3,1]: amplitudes 1/2/3 at 2 rad/s (tried only because every scalar stimulus was refused)
Category dynamic · sample time 0.1 · 60 steps · commit 93133d604 · produced by docsSample --out <folder> --blocks Gain_Scheduled_Lead_Lag Controller_1D Controller_Blend_1D Controller_2D Controller_3D Observer_Form_1D Self_Conditioned_1D Line_Of_Sight_Access Orbit_Propagator_Kepler Attitude_Dynamics Attitude_Profile_Nadir_Pointing Attitude_Profile_Geographic_Pointing Multitaper_PSD Cross_Power_Spectral_Density Transfer_Function_Estimate Envelope_Spectrum Compose_String Scan_String --steps 60 · data docs/generated/samples/Robotics__Spacecraft_Dynamics__Line_Of_Sight_Access.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).