Geocentric To Geodetic Latitude — Robotics/Axes Transformations
Robotics/Axes_Transformations/Geocentric_To_Geodetic_Latitude · 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.
Geocentric To Geodetic Latitude
Robotics / Axes Transformations
Converts the geocentric latitude – the angle at the planet's centre – and the radius to that point into the geodetic latitude a map uses. With e² = f(2−f):
- ρ = cosλ·r and z = sinλ·r, the point in cylindrical coordinates
- φ = atan2(z, ρ) to start, which is the answer for a sphere
- then, 32 times: N = R / √(1 − e²·sin²φ) and φ = atan2(z + e²·N·sinφ, ρ)
It is the exact inverse of Geodetic To Geocentric Latitude, and considerably more work: that direction is four lines of algebra, this one is a root of a quartic.
Ports
- gc – the geocentric latitude, in DEGREES. Any size [m,n]; the block works entry by entry.
- r – the distance from the planet's centre to the point, in R's length unit. The same size as gc – there is no scalar expansion.
- gd – the geodetic latitude, in DEGREES. Same size as the inputs.
Parameters
- Flattening – the ellipsoid's flattening f, a dimensionless scalar. Defaults to 0.0033528106647474805, WGS84's 1/298.257223563. Zero gives a sphere, on which the two latitudes are equal. A value of exactly 1 is refused: it is a degenerate ellipsoid with no polar extent.
- Equatorial Radius – the ellipsoid's equatorial radius R, a scalar. Defaults to WGS84's 6378137 metres, and its unit is the unit r is read in.
- 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.
Every target runs the same fixed 32 passes, and that is a deliberate choice rather than an oversight: a loop that stopped on a convergence test would stop at a different pass in different languages, and the export would then disagree with the simulation for reasons having nothing to do with the arithmetic. Thirty-two is measured – a flattening 24 times Earth's needs 24 passes to settle, and everything gentler needs eight.
The three hardware targets are simulation-only. Beyond the
sine, the square root and the arctangent, VHDL carries the running latitude
in Q16.16, because a VHDL process's scratch storage is fixed-point only;
that costs about 10−3 degrees of the final answer, well inside
the export band, and Verilog and SystemVerilog keep theirs in floating point
where they are allowed to declare one. A fixed-point port cannot carry an
Earth-sized radius at all – Q16.16 saturates past about 32767 –
so a hardware export of this block is for a small custom body or for lengths in
a larger unit. PLC Structured Text has no ATAN2 in IEC
61131-3, so it is rebuilt from ATAN with the quadrant tests written
out, inside the loop.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibtransform2/Geocentric to Geodetic Latitude.
Flattening → F and Equatorial Radius →
R, values passing straight through.
Three Simulink parameters are always implied and carry no configuration here:
ptype is always Custom, units always
Metric (MKS), and outputAltitude always off. Custom
is not cosmetic – a block left on its Earth (WGS84) setting accepts
and discards a written F or R. outputAltitude would add a
second output port carrying the height above the ellipsoid; this block
has one output, so it is pinned off. The Simulink block defines no
SampleTime, so the rate stays on the ICore side.
Notes
- Algebraic and stateless: the 32 passes all happen inside one sample and nothing survives it.
- Not linear, so the block carries no state space and model reduction correctly reports it as unmergeable.
- Bowring's single-step formula is not used, although it is the usual textbook shortcut. Measured against R2026a it reaches 3.6×10−10 degrees on Earth – 400 times outside the band this block is held to.
- Verified against R2026a: the 32-pass arrangement lands within 2.1×10−14 degrees of the Simulink block at the worst of 150 random points, at a flattening 24 times Earth's. Driven end to end through the parity rig, the exported MATLAB core agrees to 1.4×10−14 degrees.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Axes_Transformations/Geocentric_To_Geodetic_Latitude |
| family | Robotics/Axes_Transformations |
| solver environment class | ICoreBlock_0_Robotics_1_Axes_Transformations_2_Geocentric_To_Geodetic_Latitude |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Geocentric_To_Geodetic_Latitude/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Geocentric_To_Geodetic_Latitude.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Geocentric_To_Geodetic_Latitude/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Geocentric_To_Geodetic_Latitude.h |
| default size on canvas | 150 × 78 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 | gc |
| 2 | in | ICoreDouble | r |
| 3 | out | ICoreDouble | gd |
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 |
|---|---|---|
Flattening | cFmt(WGS84_F) | — |
Equatorial Radius | cFmt(WGS84_R) | — |
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 | aerolibtransform2/Geocentric to \nGeodetic Latitude |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | ptype = Custom, units = Metric (MKS), outputAltitude = off |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
CONFIG_F.c_str() | F | passes through |
CONFIG_R.c_str() | R | passes through |
Caveat (shown to the user): both latitudes are in DEGREES and the radius carries R's length unit. 'ptype' is always written as Custom, because a block left on Earth (WGS84) accepts a written F or R and discards it. 'outputAltitude' is always off: switching it on adds a SECOND output port carrying the height above the ellipsoid, and this block has one output. The Simulink block has no SampleTime, so the rate stays on the ICore side. ⚠ The two sides do not run the same algorithm -- Simulink solves the inverse directly, this block iterates 32 times -- so they agree to about 2e-14 degrees rather than bit for bit, which is the reason the parity band is 1e-12 and not 0
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B02 Simulink params rule(s) this tool cannot resolve
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).
Geocentric To Geodetic Latitude -- the angle at the planet's centre back to the map latitude rho = cos(gc) * r, z = sin(gc) * r lat = atan2(z, rho) the spherical answer, as a start repeat 32: N = R / sqrt(1 - e2 * sin(lat)^2) lat = atan2(z + e2 * N * sin(lat), rho) gd = lat
The exact inverse of Geodetic To Geocentric Latitude, and considerably more work: the forward direction is four lines of algebra, while this one is a root of a quartic and every practical method either iterates or evaluates a cube root.
⚠ THE PASS COUNT IS A CONSTANT, NOT A CONVERGENCE TEST, and that is deliberate. A loop that stops when it likes cannot be written identically in ten languages -- the stopping sample would differ by a unit in the last place between backends and the export would disagree with the simulation for reasons having nothing to do with the arithmetic. A fixed count can.
⚠ WHY THIRTY-TWO, AND IT WAS MEASURED RATHER THAN CHOSEN. The iteration contracts by roughly e2 per pass, so what it costs depends on the FLATTENING and not at all on the planet's size. Against R2026a's block, worst sample over 150 random points:
f = 1/298.26 (Earth) 8 passes 1.4e-14, and flat from there f = 0.0021 8 passes 2.8e-14, and flat from there f = 0.081 (24x Earth) 8 -> 1.6e-05, 16 -> 5.9e-11, 24 -> 2.1e-14, 32 -> 2.1e-14
The parity rig runs the last of those on purpose -- see its entry -- so 24 is the measured requirement and 32 is the margin.
⚠ AND BOWRING'S SINGLE STEP IS NOT ENOUGH. The usual textbook shortcut reaches 3.6e-10 on Earth, which is 400 times outside the band this block is held to; iterating IT made matters worse rather than better, because its auxiliary angle is not the thing the recursion contracts. The plain formulation above is what converges.
ALGEBRAIC and STATELESS: the 32 passes happen inside one sample, and nothing survives it.
Sample results#
| t | in ICoreDouble-Out-0 | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|---|
| 0 | -2 | -2 | 90 |
| 0.4 | 0.5 | 0.5 | 90 |
| 0.8 | -2 | -2 | 90 |
| 1.2 | 0.5 | 0.5 | 90 |
| 1.6 | -2 | -2 | 90 |
| 2 | 0.5 | 0.5 | 90 |
| 2.4 | -2 | -2 | 90 |
| 2.8 | 0.5 | 0.5 | 90 |
| 3.2 | -2 | -2 | 90 |
| 3.6 | 0.5 | 0.5 | 90 |
| 4 | -2 | -2 | 90 |
| 4.4 | 0.5 | 0.5 | 90 |
| 4.8 | -2 | -2 | 90 |
| 5.2 | 0.5 | 0.5 | 90 |
Every 4th of 60 samples, from the table stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 90 |
ramp | Ramp: slope 1 from t = 0 | 0 … 90 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 90 |
step | Step: 0 -> 1 at t = 1 s | 0 … 90 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit d541288cd5ad49da343fa0a3f9debc142164f671 · produced by docsSample --out <folder> --blocks Geodetic_To_Geocentric_Latitude Geocentric_To_Geodetic_Latitude --steps 60 · data docs/generated/samples/Robotics__Axes_Transformations__Geocentric_To_Geodetic_Latitude.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).