Cartesian To Polar — Robotics/Coordinate Transforms
Robotics/Coordinate_Transforms/Cartesian_To_Polar · 2 input / 2 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.
Cartesian To Polar
Robotics / Coordinate Transforms
Converts a planar Cartesian pair to polar form, entry by entry: r = √(x² + y²) and θ = atan2(y, x), with θ in (−π, π].
The four-quadrant arctangent is the whole point: a plain
atan(y/x) collapses the second and third quadrants onto the
first and fourth, and loses the sign of a purely vertical vector
entirely.
Ports
- x – the abscissa, any size [m,n].
- y – the ordinate. It must be the same size as x; the two are paired entry by entry and neither is broadcast.
- r – the radius √(x² + y²), the same size as the inputs. Never negative.
- theta – the angle atan2(y, x) in radians, the same size as the inputs.
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 three HDL targets are simulation-only: they carry the
arithmetic in real and quantize only at the port boundary. A
square root and a four-quadrant arctangent have no Q16.16 form to call, so
offering them as synthesizable would be a claim the generated core could not
keep.
PLC Structured Text has no ATAN2 in IEC 61131-3, so the
angle is rebuilt from ATAN(y/x) with the quadrant reconstruction
– including the x = 0 axes and the origin, where the quotient is
undefined. The result is the same value the other nine targets produce.
Simulink bridge
Both directions, onto
simulink_extras/Transformations/Cartesian to Polar. That block has
no dialog parameters whatsoever (verified with
get_param(blk, 'DialogParameters'), which comes back empty), so
there is nothing to map: the bridge is the library path alone. It also has
no SampleTime parameter, so Sampling Time (s) does
not cross – the block runs at the surrounding Simulink rate, and a rate
set here stays on the ICore side.
Notes
- Algebraic and stateless: both outputs depend only on the current inputs, so the block cannot break an algebraic loop.
- Nonlinear, and deliberately carries no state space – a fabricated linear form would let model reduction merge matrices that do not describe this block.
- π belongs to the negative x-axis. At y = 0 and x < 0 the angle is +π, not −π; the range is half-open at the negative end. This is measured against the Simulink block, not inherited from a convention.
- At the origin both outputs are zero. atan2(0, 0) = 0 here, in Simulink, in C and in MATLAB. The angle is of course undefined there in mathematics – zero is the shared convention, not an answer.
- The inverse is Polar To Cartesian, and the pair round-trips exactly for any θ already inside (−π, π].
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Coordinate_Transforms/Cartesian_To_Polar |
| family | Robotics/Coordinate_Transforms |
| solver environment class | ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_Cartesian_To_Polar |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Robotics/Coordinate_Transforms/Cartesian_To_Polar/ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_Cartesian_To_Polar.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Robotics/Coordinate_Transforms/Cartesian_To_Polar/ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_Cartesian_To_Polar.h |
| default size on canvas | 126 × 84 px |
| ports at insert | 2 in, 2 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 | x |
| 2 | in | ICoreDouble | y |
| 3 | out | ICoreDouble | r |
| 4 | out | ICoreDouble | theta |
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 | simulink_extras/Transformations/Cartesian to Polar |
| 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 Simulink block has no dialog parameters at all, so nothing but the block itself crosses; it also defines no SampleTime, so "Sampling Time (s)" does not cross and the block runs at the surrounding Simulink rate
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
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).
Cartesian To Polar — the planar transform, elementwise r = sqrt(x^2 + y^2) theta = atan2(y, x) in (-pi, pi]
The Robotics grand family's first block and its parity anchor. No config at all: the Simulink counterpart has an EMPTY DialogParameters, so the §5 entry is a library path and
hasSampleTimeParam = false, with nothing else that can be wrong.Every convention here was measured against the real R2026a block with an 11-point probe table -- port order, the (-pi, pi] range with +pi on the negative x-axis, and theta = 0 at the origin. See the header.
Two backends do NOT give the origin for free, and both are handled below rather than left to chance, because each fails in a way that does not look like this block:
- VHDL's math_real ARCTAN(Y, X) ASSERTS at (0.0, 0.0) instead of returning a value, and an
assertion aborts the WHOLE simulation -- so the core reads as broken rather than as one out-of-domain sample. Guarded, answering 0, which is what Simulink and C both answer.
- IEC 61131-3 has no ATAN2 at all. It is rebuilt from ATAN(y/x) with the quadrant
reconstruction, the x = 0 axes and the origin split out because y/x is undefined there.
Both are Trigonometric_Function's solutions for its own atan2 mode, reused verbatim rather than re-derived -- that block already paid for finding them.
Sample results#
| t | in ICoreDouble-Out-0 | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 | out ICoreDouble-Out-1 |
|---|---|---|---|---|
| 0 | -2 | -2 | 2.828 | -2.356 |
| 0.4 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 0.8 | -2 | -2 | 2.828 | -2.356 |
| 1.2 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 1.6 | -2 | -2 | 2.828 | -2.356 |
| 2 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 2.4 | -2 | -2 | 2.828 | -2.356 |
| 2.8 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 3.2 | -2 | -2 | 2.828 | -2.356 |
| 3.6 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 4 | -2 | -2 | 2.828 | -2.356 |
| 4.4 | 0.5 | 0.5 | 0.7071 | 0.7854 |
| 4.8 | -2 | -2 | 2.828 | -2.356 |
| 5.2 | 0.5 | 0.5 | 0.7071 | 0.7854 |
Every 4th of 60 samples, from the table stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 1.414 |
ramp | Ramp: slope 1 from t = 0 | 0 … 8.202 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 1.414 |
step | Step: 0 -> 1 at t = 1 s | 0 … 1.414 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Robotics__Coordinate_Transforms__Cartesian_To_Polar.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).