Rotation Matrix To Wind Angles — Robotics/Axes Transformations
Robotics/Axes_Transformations/Rotation_Matrix_To_Wind_Angles · 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 Wind Angles
Robotics / Axes Transformations
Reads the bank, flight path and heading angles back out of the [3,3] direction cosine matrix they describe. It is the inverse of Wind Angles To Rotation Matrix, whose forward form has
- DCM00 = cosγ·cosχ, DCM01 = cosγ·sinχ, DCM02 = −sinγ
- DCM12 = sinμ·cosγ, DCM22 = cosμ·cosγ
so the extraction is three calls:
- μ = atan2(DCM12, DCM22) – the bank angle.
- γ = asin(−DCM02) – the flight path angle.
- χ = atan2(DCM01, DCM00) – the heading.
The output is ordered bank first, matching the order Wind Angles To Rotation Matrix takes them and the order the Simulink block returns them – which is the reverse of the order the same three angles come out of a ZYX extraction. The arithmetic is that extraction; only the publication order differs.
Ports
- DCM – the matrix, [3,3]. The size is fixed.
- angles – the three angles in radians, a [3,1] column [μ; γ; χ] – bank, flight path, heading. 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.
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 two atan2 go through real arithmetic and only the ports quantize.
Simulink bridge
Both directions, onto
aerolibtransform2/Direction Cosine Matrix to Wind Angles 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 two lines, so the real library path carries one
embedded newline, between to and Wind – not two, unlike its
siblings in this family. The flattened one-line spelling resolves to nothing. 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 triple as a row; this one returns a column.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Bank comes FIRST. That is the order this family's forward block takes and the Simulink block returns, and it is the reverse of a ZYX extraction, which publishes heading first. Both are ordinary numbers, so swapping them is invisible to every check except a comparison against a reference.
- Angles are radians, on this port and on both sides of the bridge.
- 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.
- At a flight path of ±90° the bank and the heading stop being separately determined and both atan2 calls approach atan2(0, 0), which every target answers as 0. Nothing is signalled; the result is still a valid representative.
- Orthonormality is not checked. The three 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_Wind_Angles |
| family | Robotics/Axes_Transformations |
| solver environment class | ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Wind_Angles |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Rotation_Matrix_To_Wind_Angles/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Wind_Angles.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Rotation_Matrix_To_Wind_Angles/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Rotation_Matrix_To_Wind_Angles.h |
| default size on canvas | 146 × 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 | angles |
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 to\nWind Angles |
| 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. THE OUTPUT ORDER IS BANK, FLIGHT PATH, HEADING -- the reverse of a ZYX extraction, measured on the same matrix. It returns the triple as a row where this block returns a column, and it defines no SampleTime parameter: an ICore rate set explicitly stays on this side
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 Wind Angles — the matrix back to bank, flight path and heading mu = atan2(DCM(1,2), DCM(2,2)) bank gamma = asin(clamp(-DCM(0,2))) flight path chi = atan2(DCM(0,1), DCM(0,0)) heading
The inverse of Wind_Angles_To_Rotation_Matrix.
MEASURED against aerolibtransform2/Direction Cosine Matrix to Wind Angles (R2026a, 2026-09-10): on the matrix of (mu, gamma, chi) = (0.41, -0.28, 1.05) it returns [0.41 -0.28 1.05], and the three formulas above reproduce that to the last bit.
⚠⚠ THE OUTPUT ORDER IS BANK FIRST, WHICH IS THE REVERSE OF A ZYX EXTRACTION. The same measurement: dcm2angle(D, 'ZYX') answers [1.05 -0.28 0.41] on that matrix - chi, gamma, mu - where this block answers mu, gamma, chi. The arithmetic is identical; only the publication order differs, and reading one for the other swaps two ordinary numbers that nothing anywhere reports.
⚠ ITS LIBRARY PATH CARRIES ONE EMBEDDED NEWLINE, between "to" and "Wind" - not two, unlike its two siblings in this family. Measured, not assumed.
⚠ SIMULATION-ONLY on the three HDL targets: an asin and two atan2.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Rotation Matrix To Wind Angles block: ICore Blocks/Home/Rotation Matrix To Wind Angles. 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_Wind_Angles.json