Rotation Angles To Rodrigues — Robotics/Orientation 3D
Robotics/Orientation_3D/Rotation_Angles_To_Rodrigues · 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 Angles To Rodrigues
Robotics / Orientation 3D
Converts three rotation angles [r1; r2; r3] of a chosen rotation order, applied r1 first, into the [3,1] Rodrigues vector of the same rotation – the Gibbs vector r = tan(θ/2)·n̂. It is the inverse of Rodrigues To Rotation Angles.
It composes quaternions rather than building a matrix. Writing (a, b, c) for the axes the order names and qk(α) = [cos(α/2), sin(α/2)êk]:
- q = qa(r1) ⊗ qb(r2) ⊗ qc(r3)
- r = [qx/qw qy/qw qz/qw]T
Each elementary quaternion has only two nonzero components, and those zeros are folded away when the code is generated, so the whole conversion costs six trigonometric calls, eight multiply-adds and three divisions in every target – whatever the order.
Ports
- angles – the three angles in radians, a [3,1] column [r1; r2; r3], in the order they are applied. The size is fixed: three numbers.
- r – the Rodrigues vector, a [3,1] column. Its size is fixed.
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.
- ZYZ, ZXZ, YXY, YZY, XYX, XZX – the six proper Euler orders, whose first and third axes are the same.
- 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 components of the three elementary quaternions are nonzero, so it is not offered as a tunable parameter on the generated core. Changing it means exporting again.
The three components are each divided by the scalar part, rather than multiplied by one shared reciprocal. That is the opposite of what Quaternion Inverse and Rodrigues To Quaternion do, and it is deliberate: a VHDL block body has no real-typed scratch variable to hold a reciprocal in, so hoisting one would round differently in six targets from the other four.
On the three HDL targets the block is offered as simulation-only: a Q16.16 datapath has neither trigonometry nor division, so all of it goes through real arithmetic and only the ports quantize.
Simulink bridge
Both directions, onto aerolibtransform2/Rotation Angles to Rodrigues 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.
- Angles are radians, never degrees, on both ports and on both sides of the bridge.
- The scalar part vanishes at a half turn. The composed rotation reaching 180° is exactly where the Gibbs vector is infinite, its coordinates having no point there. The six software targets answer infinity or NaN; the three fixed-point targets answer zero, because fixed point has neither. Nothing is logged. Feed Rotation Angles To Quaternion – Euler To Quaternion, for the default order – if the rotation can reach a half turn.
- Round-tripping is exact up to the angle ranges. Sending the result through Rodrigues To Rotation Angles at the same order returns the same angles whenever they lie in that order's principal ranges, and an equivalent set otherwise.
- MATLAB reaches the same answer by a different route – it builds the direction cosine matrix and reads the vector back off it, where this block composes quaternions. The two are the same map; measured over all twelve orders they agree to 3.3e-16.
- Deliberately no state space – the map is not linear.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Orientation_3D/Rotation_Angles_To_Rodrigues |
| family | Robotics/Orientation_3D |
| solver environment class | ICoreBlock_0_Robotics_1_Orientation_3D_2_Rotation_Angles_To_Rodrigues |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Orientation_3D/Rotation_Angles_To_Rodrigues/ICoreBlock_0_Robotics_1_Orientation_3D_2_Rotation_Angles_To_Rodrigues.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Orientation_3D/Rotation_Angles_To_Rodrigues/ICoreBlock_0_Robotics_1_Orientation_3D_2_Rotation_Angles_To_Rodrigues.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 | angles |
| 2 | out | ICoreDouble | r |
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/Rotation Angles to Rodrigues |
| 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).
Rotation Angles To Rodrigues — [r1; r2; r3] in a chosen order to the [3,1] Gibbs vector With (a, b, c) the axis indices of the order's three letters and
q_k(alpha) = [ cos(alpha/2), sin(alpha/2) * e_k ]
the rotation is q = q_a(r1) (x) q_b(r2) (x) q_c(r3) and the answer is r = [ q(1)/q(0), q(2)/q(0), q(3)/q(0) ].
Each elementary quaternion has only TWO nonzero components, and the zeros are folded HERE, at export time, rather than emitted as multiplications by literal zero - so the two products cost eight multiply-adds in every backend whatever the order.
MEASURED against MATLAB's angle2rod for ALL TWELVE orders on [0.41 -0.73 1.17]: worst disagreement 3.33e-16. MATLAB builds the direction cosine matrix and reads it back; the two routes are the same map and differ only in rounding.
⚠ THE PRODUCT IS q_a (x) q_b (x) q_c, IN THAT ORDER. The angles are applied r1 FIRST, whose direction cosine matrix is R_c(r3) * R_b(r2) * R_a(r1); the reversal between the two is what turns a passive matrix product into a quaternion product. Written backwards it is right for every input whose angles happen to commute and wrong for the rest.
⚠ THREE DIVISIONS BY THE SAME SCALAR, not one shared reciprocal, and against this family's usual contract. A VHDL block body has no real-typed scratch variable to hold a reciprocal in, so hoisting one would round differently in six targets from the other four; uniformity across the ten is worth more here than one saved division.
⚠ SIMULATION-ONLY on the three HDL targets: six trigonometric calls and three divisions.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Rotation Angles To Rodrigues block: ICore Blocks/Home/Rotation Angles To Rodrigues. 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__Rotation_Angles_To_Rodrigues.json