Rotation Matrix To Latitude Longitude — Robotics/Axes Transformations
Robotics/Axes_Transformations/Rotation_Matrix_To_Latitude_Longitude · 1 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.
Rotation Matrix To Latitude Longitude
Robotics / Axes Transformations
Reads the geodetic latitude and longitude back out of the [3,3] ECEF-to-NED direction cosine matrix they describe. It is the inverse of ECEF To NED Rotation Matrix, whose forward form is
- DCM10 = −sin(lon), DCM11 = cos(lon), DCM12 = 0
- DCM22 = −sin(lat)
so the extraction is two calls and a unit conversion:
- lat = asin(−DCM22) · 180/π
- lon = atan2(−DCM10, DCM11) · 180/π
Latitude is taken from DCM22 and not from DCM02: that entry is cos(lat), which gives the magnitude without the sign and folds the southern hemisphere onto the northern one. Longitude is taken from row 1, whose two entries carry no latitude at all, so it stays defined at either pole.
Ports
- DCM – the ECEF-to-NED matrix, [3,3]. The size is fixed.
- latlon – the geodetic position in degrees, a [2,1] column [latitude; longitude], in the same order and units ECEF To NED Rotation Matrix takes them. Its size is fixed and does not follow the input's.
Parameters
- 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. There is no tunable parameter, because the block has no parameter at all – the matrix arrives on a port.
180/π is embedded as a literal at full double precision, the same digits in every target, so the ten backends agree bit for bit on the conversion as well as on the trigonometry.
On the three HDL targets the block is offered as simulation-only: a Q16.16 datapath has no inverse trigonometric function, so the asin and the atan2 go through real arithmetic and only the ports quantize. Note that a longitude in degrees reaches 180, which is well inside Q16.16's range but leaves only about four decimal places of it.
Simulink bridge
Both directions, onto
aerolibtransform2/Direction Cosine Matrix ECEF to NED to Latitude and Longitude in
the Aerospace Blockset. Its two dialog parameters do not cross and are listed as
ignored: action and tolerance select what the Simulink block does when
the matrix is not orthonormal, and this block validates nothing.
The block's name is drawn on three lines, so the real library path carries two
embedded newlines – after Matrix and after NED. The flattened
one-line spelling resolves to nothing, silently. And the block defines no
SampleTime parameter, so the rate stays on this side and a block configured
with an explicit positive rate reports that the rate did not cross.
The Simulink block returns the pair as a row; this one returns a column.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Both outputs are DEGREES. That is the Aerospace convention and it is what the forward block in this family takes; its sibling Rotation Matrix To Alpha Beta uses radians, because the Aerospace block it mirrors does. The two conventions sit side by side here for that reason and for no other.
- The asin argument is clamped to [−1, 1]. On an exact rotation matrix it is already inside it; the clamp is what keeps rounding at the boundary from producing NaN in six targets, a complex number in MATLAB and an aborted simulation in VHDL.
- Latitude comes back in [−90, 90] and longitude in (−180, 180], which are asin's and atan2's ranges. A forward block driven with a longitude of 200° therefore round-trips to −160° – the same meridian, a different representative.
- Orthonormality is not checked. The two formulas are evaluated on whatever arrives.
- Deliberately no state space – the map is not linear.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Axes_Transformations/Rotation_Matrix_To_Latitude_Longitude |
| family | Robotics/Axes_Transformations |
| solver environment class | ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Latitude_Longitude |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Rotation_Matrix_To_Latitude_Longitude/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Latitude_Longitude.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Rotation_Matrix_To_Latitude_Longitude/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Latitude_Longitude.h |
| default size on canvas | 150 × 70 px |
| ports at insert | 1 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 | DCM |
| 2 | out | ICoreDouble | latlon |
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#
No config variable beyond the Sampling Time (s) every block carries.
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/Direction Cosine Matrix\nECEF to NED\nto Latitude and Longitude |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): MEASURED 2026-09-10: the Simulink block's only dialog parameters are 'action' (None/Warning/Error) and 'tolerance', which decide what it does when the matrix is not orthonormal. Neither crosses: this block validates nothing. BOTH OUTPUTS ARE DEGREES on either side. Its library path carries TWO embedded newlines, the name being drawn on three lines, and it returns the pair as a row where this block returns a column. It defines no SampleTime parameter: an ICore rate set explicitly stays on this side and is reported
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:
B0every stimulus in the sample errored — cross-checks skipped
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).
Rotation Matrix To Latitude Longitude — the ECEF-to-NED matrix back to a geodetic position lat = asin(clamp(-DCM(2,2))) * 180/pi lon = atan2(-DCM(1,0), DCM(1,1)) * 180/pi
The inverse of ECEF_To_NED_Rotation_Matrix, whose forward form is
DCM = | -clo*sla -slo*sla cla | | -slo clo 0 | | -clo*cla -slo*cla -sla |
MEASURED against aerolibtransform2/Direction Cosine Matrix ECEF to NED to Latitude and Longitude (R2026a, 2026-09-10): on the matrix of (37.4, -122.1) degrees it returns exactly those two, and the formulas above reproduce them to the last bit.
⚠ BOTH OUTPUTS ARE DEGREES, as the Simulink block returns them and as this family's forward block takes them. Reading them as radians is not an error anywhere - it is a position on the wrong part of the planet.
⚠ LATITUDE COMES FROM DCM(2,2), NOT FROM DCM(0,2). The (0,2) entry is cos(lat) and gives the magnitude without the sign, so a form built on it folds the southern hemisphere onto the northern one. MEASURED at lat = 37.4: asin(-DCM(2,2)) answers 37.4, atan2(DCM(0,2), -DCM(2,2)) answers 52.6.
⚠ ROW 1 CARRIES LONGITUDE ALONE - its two entries hold no latitude - so the longitude stays defined at either pole, where every other entry has collapsed.
⚠ ITS LIBRARY PATH CARRIES TWO EMBEDDED NEWLINES: the name is drawn on three lines.
⚠ SIMULATION-ONLY on the three HDL targets: an asin and an atan2.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Rotation Matrix To Latitude Longitude block: ICore Blocks/Home/Rotation Matrix To Latitude Longitude. That is a fact about the single-block rig, not a verdict on the block: an offline batch fit, a block whose output only appears at onSolverFinish, or one that needs a driven environment cannot be exercised alone.
Category unsampled · sample time 0.1 · 60 steps · commit c29996956 · produced by docsSample --out <folder> --blocks Direction_Cosine_Matrix_To_Rotation_Angles Rotation_Matrix_To_Alpha_Beta Rotation_Matrix_To_Latitude_Longitude Rotation_Matrix_To_Wind_Angles --steps 60
Sample data: docs/generated/samples/Robotics__Axes_Transformations__Rotation_Matrix_To_Latitude_Longitude.json