Rodrigues To Rotation Angles — Robotics/Orientation 3D
Robotics/Orientation_3D/Rodrigues_To_Rotation_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.
Rodrigues To Rotation Angles
Robotics / Orientation 3D
Converts a [3,1] Rodrigues vector r – the Gibbs vector r = tan(θ/2)·n̂ – into the three rotation angles [r1; r2; r3] of a chosen rotation order, applied r1 first. It does it in two closed-form steps: the direction cosine matrix D of r (exactly as Rodrigues To Direction Cosine Matrix builds it), then the standard extraction for that order.
Writing (a, b, c) for the axes the order names and ε = +1 when b is the cyclic successor of a (−1 otherwise), the extraction is one rule with two branches:
- Tait-Bryan (three different axes, e.g. ZYX): r2 = asin(εDca), r1 = atan2(−εDcb, Dcc), r3 = atan2(−εDba, Daa).
- Proper Euler (first and third axes equal, e.g. ZYZ, with d the axis the order never names): r2 = acos(Daa), r1 = atan2(Dab, −εDad), r3 = atan2(Dba, εDda).
Only five matrix entries are ever built, so the cost does not depend on the order. Rotation Angles To Rodrigues is the inverse.
Ports
- r – the Rodrigues vector, a [3,1] column. The size is fixed: three numbers.
- angles – the three angles in radians, a [3,1] column [r1; r2; r3], in the order they are applied. Its size is fixed and does not follow the input's.
Parameters
- Rotation Order – which three axes the angles turn about, and in which order
r1, r2, r3 are applied. Twelve values, the
same twelve the Simulink block offers and with the same names:
- ZYX – the default, and the aerospace yaw–pitch–roll set.
- ZXY, YXZ, YZX, XYZ, XZY – the other five Tait-Bryan orders, each naming three different axes. The middle angle comes from an asin and lies in [−π/2, π/2].
- ZYZ, ZXZ, YXY, YZY, XYX, XZX – the six proper Euler orders, whose first and third axes are the same. The middle angle comes from an acos and lies in [0, π].
- 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 rotation order is structural and is baked into the exported body: it decides which five matrix entries the code reads, so it is not offered as a tunable parameter on the generated core. Changing it means exporting again.
On the three HDL targets the block is offered as simulation-only: a Q16.16 datapath has neither a reciprocal nor an inverse trigonometric function, so all of it goes through real arithmetic and only the ports quantize. This is the same choice Quaternion To Euler makes.
Simulink bridge
Both directions, onto aerolibtransform2/Rodrigues to Rotation Angles in
the Aerospace Blockset. One parameter pair crosses: Rotation Order →
rotationOrder, and the translation is lossless in both directions because
the twelve names are identical on the two sides.
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 uses rows at both ports; this one uses columns, as every vector port in this family does.
Notes
- Algebraic, with no state: the output depends only on the current input and the configured order.
- A proper-Euler middle angle is never negative. acos returns [0, π], so a rotation whose natural middle angle is negative comes back as its positive twin with r1 and r3 shifted by π – the same rotation, a different representative. MATLAB does exactly the same thing.
- Angles are radians, never degrees, on both ports and on both sides of the bridge.
- Gimbal lock is not signalled. When the middle angle reaches the end of its range the first and third angles stop being separately determined and both atan2 calls approach atan2(0, 0), which every target answers as 0. The result is still a valid representative of the rotation; it is simply not the only one.
- The asin and acos arguments are clamped to [−1, 1] before use. On an exact rotation matrix they are 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.
- Deliberately no state space – the map is not linear.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Orientation_3D/Rodrigues_To_Rotation_Angles |
| family | Robotics/Orientation_3D |
| solver environment class | ICoreBlock_0_Robotics_1_Orientation_3D_2_Rodrigues_To_Rotation_Angles |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Orientation_3D/Rodrigues_To_Rotation_Angles/ICoreBlock_0_Robotics_1_Orientation_3D_2_Rodrigues_To_Rotation_Angles.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Orientation_3D/Rodrigues_To_Rotation_Angles/ICoreBlock_0_Robotics_1_Orientation_3D_2_Rodrigues_To_Rotation_Angles.h |
| default size on canvas | 140 × 76 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 | r |
| 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#
| Config variable | Default | Simulink parameter |
|---|---|---|
Rotation Order | combo | — |
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/Rodrigues to Rotation Angles |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
CONFIG_ORDER.c_str() | rotationOrder | ZYX → ZYX, ZYZ → ZYZ, ZXY → ZXY, ZXZ → ZXZ, YXZ → YXZ, YXY → YXY, YZX → YZX, YZY → YZY, XYZ → XYZ, XYX → XYX, XZY → XZY, XZX → XZX |
Caveat (shown to the user): MEASURED 2026-09-10: the Simulink block's only dialog parameter is rotationOrder, with the same twelve names this block offers, so the translation is one-to-one and lossless in both directions. It uses rows at both ports where this block uses columns, and 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:
B01 Simulink params rule(s) this tool cannot resolveB0every 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).
Rodrigues To Rotation Angles — a [3,1] Gibbs vector to [r1; r2; r3] in a chosen order Two steps, both closed form:
- the direction cosine matrix of r, D(i,j), exactly as Rodrigues To Direction Cosine
Matrix builds it - n = r.r, den = 1 + n, and D(i,i) = (1 + 2*r(i)^2 - n) / den D(i,j) = 2*(r(i)*r(j) +/- r(k)) / den
- the standard extraction for the order's three axes (a, b, c), with
eps = +1 when b is the cyclic successor of a and -1 otherwise:
a /= c : r2 = asin(clamp(eps*D(c,a))) r1 = atan2(-eps*D(c,b), D(c,c)) r3 = atan2(-eps*D(b,a), D(a,a)) a == c : r2 = acos(clamp(D(a,a))) (d = the third axis) r1 = atan2(D(a,b), -eps*D(a,d)) r3 = atan2(D(b,a), eps*D(d,a))
MEASURED against aerolibtransform2/Rodrigues to Rotation Angles (R2026a, 2026-09-10). The block agrees with MATLAB's rod2angle exactly, and rod2angle agrees with dcm2angle(rod2dcm(r)) exactly, so the two-step reading above is the reference's own. The formulas here were then checked against dcm2angle on r = [0.37 -0.62 0.21] for ALL TWELVE orders: worst disagreement 2.22e-16.
⚠ THE EXTRACTION RULE HAS ONE TEXTUAL FORM, angleExprs() below, and all TEN generators read it - twelve orders times ten backends would otherwise be 120 transcriptions of five index pairs. compute_h carries the NUMERIC twin of the same rule rather than reading that one: one builds strings and the other doubles, so they cannot be the same function. They are written in the same order with the same names, which is what makes a divergence visible reading the two side by side - and export verification is what would catch one.
⚠ ONLY FIVE MATRIX ENTRIES ARE EVER BUILT, not nine - the extraction never reads the other four - so the emitted body is the same size whatever the order.
⚠ ACOS RETURNS [0, pi], so a proper-Euler middle angle is never negative; MATLAB behaves the same way, measured, and the description says so.
⚠ SIMULATION-ONLY on the three HDL targets: a reciprocal and three inverse trigonometric functions per sample.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Rodrigues To Rotation Angles block: ICore Blocks/Home/Rodrigues To Rotation 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 b286d2937 · produced by docsSample --out <folder> --blocks Rodrigues_To_Direction_Cosine_Matrix Direction_Cosine_Matrix_To_Rodrigues Rodrigues_To_Quaternion Quaternion_To_Rodrigues Rodrigues_To_Rotation_Angles Rotation_Angles_To_Rodrigues --steps 60
Sample data: docs/generated/samples/Robotics__Orientation_3D__Rodrigues_To_Rotation_Angles.json