Wind Angles To Rotation Matrix — Robotics/Axes Transformations
Robotics/Axes_Transformations/Wind_Angles_To_Rotation_Matrix · 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.
Wind Angles To Rotation Matrix
Robotics / Axes Transformations
Builds the [3,3] direction cosine matrix described by the three wind angles – bank μ, flight path γ and heading χ. Writing c and s for cosine and sine:
- DCM00 = cγ·cχ, DCM01 = cγ·sχ, DCM02 = −sγ
- DCM10 = sμ·sγ·cχ − cμ·sχ, DCM11 = sμ·sγ·sχ + cμ·cχ, DCM12 = sμ·cγ
- DCM20 = cμ·sγ·cχ + sμ·sχ, DCM21 = cμ·sγ·sχ − sμ·cχ, DCM22 = cμ·cγ
The rotations are applied heading first, then flight path, then bank – so the port order is the reverse of the order they happen in.
Ports
- angles – the three wind angles in radians, as a [3,1] column [μ; γ; χ]: row 0 is the bank, row 1 the flight path angle and row 2 the heading. Any value is accepted, and an angle outside ±π simply wraps.
- DCM – the direction cosine matrix, [3,3]. 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.
There are no others: all three angles arrive on the port.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text.
The three hardware targets are simulation-only: the matrix needs six sines and cosines, and no fixed-point sine is available to a block body, so those exports convert at the port boundary and compute in floating point. They simulate correctly and are not offered as synthesizable. The other seven are exact.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibtransform2/Wind Angles to Direction Cosine Matrix. That block
has no dialog parameters at all – measured in R2026a – so
nothing is mapped, and it defines no SampleTime either: the
rate stays on the ICore side and a block given an explicit positive period
reports that it did not cross.
Notes
- Algebraic and stateless: the matrix depends on this sample alone.
- Not linear, so the block carries no state space and model reduction correctly reports it as unmergeable.
- The port order is the reverse of the rotation order, and that is the one thing worth checking twice about this block. Row 0 is the bank angle, applied last. Feeding the heading there instead gives a matrix that is still orthogonal and still plausible, and wrong by as much as 1.63.
- Verified against R2026a: over 200 random angle triples, this block and the Simulink one agree to 1.1×10−16.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Axes_Transformations/Wind_Angles_To_Rotation_Matrix |
| family | Robotics/Axes_Transformations |
| solver environment class | ICoreBlock_0_Robotics_1_Axes_Transformations_2_Wind_Angles_To_Rotation_Matrix |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Wind_Angles_To_Rotation_Matrix/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Wind_Angles_To_Rotation_Matrix.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Axes_Transformations/Wind_Angles_To_Rotation_Matrix/ICoreBlock_0_Robotics_1_Axes_Transformations_2_Wind_Angles_To_Rotation_Matrix.h |
| default size on canvas | 150 × 84 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 | angles |
| 2 | out | ICoreDouble | DCM |
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/Wind Angles to \nDirection Cosine Matrix |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): the Aerospace Blockset block is a masked subsystem with no dialog parameters at all: the three angles arrive on one port as [bank; flight path; heading] and the matrix leaves on one, so nothing but the signal crosses. It defines no SampleTime either, so 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).
Wind Angles To Rotation Matrix -- bank, flight path and heading to the [3,3] matrix they describe DCM = | cth*cps cth*sps -sth | | sph*sth*cps - cph*sps sph*sth*sps + cph*cps sph*cth | | cph*sth*cps + sph*sps cph*sth*sps - sph*cps cph*cth |
writing cph/sph for the bank angle mu, cth/sth for the flight path angle gamma and cps/sps for the heading chi. All three arrive on ONE port as a [3,1] column in radians, which is the shape the Aerospace Blockset block uses.
⚠⚠ THE SEQUENCE RUNS HEADING FIRST AND THE PORT ORDER RUNS THE OTHER WAY. Row 0 of the input is the BANK angle -- the LAST rotation applied -- and row 2 is the heading, the first. Both readings are equally reasonable from a port list, and only one of them is the block: measured over 200 random triples, this matrix agrees with R2026a to 1.1e-16, while the reading that takes row 0 as the heading is out by as much as 1.63, which is most of the matrix. The measurement is what settled it, and it is the reason the three angle names are spelled out on the ports rather than left as a vector label.
ALGEBRAIC and STATELESS, and nonlinear in its input, so the block carries no state space.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Wind Angles To Rotation Matrix block: ICore Blocks/Home/Wind Angles To Rotation Matrix. 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 d60dae4fbffb95396a5d3d2dc3582537a193a262 · produced by docsSample --out <folder> --blocks Body_To_Wind_Rotation_Matrix Wind_Angles_To_Rotation_Matrix ECEF_To_NED_Rotation_Matrix --steps 60
Sample data: docs/generated/samples/Robotics__Axes_Transformations__Wind_Angles_To_Rotation_Matrix.json